From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0226.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0226.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0226.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0225.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0224.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0224.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0224.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0223.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0218.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0217.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0217.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0227.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0227.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0227.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0226.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0225.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0225.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0225.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0224.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0219.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0218.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0218.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0228.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0228.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0228.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0227.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0226.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0226.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0226.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0225.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0220.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0219.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0219.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0229.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0229.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0229.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0228.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0227.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0227.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0227.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0226.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0221.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0220.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0220.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0230.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0230.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0230.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0229.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0228.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0228.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0228.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0227.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0222.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0221.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0221.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0231.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0231.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0231.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0230.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0229.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0229.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0229.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0228.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0223.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0222.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0222.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0232.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0232.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0232.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0231.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0230.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0230.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0230.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0229.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0224.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0223.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0223.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0233.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0233.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0233.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0232.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0231.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0231.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0231.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0230.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0225.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0224.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0224.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0234.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0234.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0234.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0233.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0232.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0232.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0232.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0231.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0226.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0225.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0225.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0235.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0235.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0235.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0234.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0233.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0233.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0233.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0232.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0227.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0226.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0226.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0001.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0001.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0001.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0001.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0001.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0001.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0001.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0001.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0001.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0001.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0002.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0002.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0002.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0002.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0002.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0002.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0002.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0002.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0002.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0002.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0003.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0003.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0003.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0003.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0003.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0003.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0003.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0003.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0003.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0003.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0004.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0004.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0004.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0004.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0004.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0004.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0004.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0004.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0004.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0004.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0005.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0005.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0005.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0005.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0005.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0005.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0005.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0005.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0005.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0005.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0005.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0006.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0006.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0006.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0006.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0006.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0006.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0006.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0006.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0006.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0006.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0006.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0007.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0007.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0007.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0007.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0007.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0007.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0007.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0007.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0007.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0007.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0007.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0008.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0008.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0008.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0008.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0008.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0008.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0008.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0008.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0008.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0008.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0008.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0009.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0009.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0009.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0009.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0009.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0009.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0009.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0009.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0009.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0009.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0009.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0010.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0010.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0010.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0010.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0010.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0010.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0010.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0010.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0010.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0010.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0010.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0001.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0001.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0001.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0001.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0001.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0001.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0001.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0001.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0001.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0001.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0002.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0002.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0002.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0002.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0002.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0002.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0002.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0002.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0002.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0002.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0003.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0003.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0003.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0003.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0003.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0003.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0003.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0003.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0003.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0003.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0004.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0004.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0004.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0004.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0004.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0004.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0004.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0004.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0004.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0004.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0005.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0005.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0005.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0005.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0005.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0005.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0005.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0005.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0005.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0005.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0005.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0006.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0006.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0006.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0006.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0006.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0006.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0006.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0006.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0006.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0006.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0006.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0007.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0007.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0007.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0007.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0007.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0007.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There is an actual bit flipped that we can indirectly > see > on most OSes. So we can follow with basically a flush() call. Flush > returns when the data is written. > > So you can do one of two things... see if the data is flushed with your > own flush call then flip the RTS or look through the native code and > make > sure there isnt a code path that can produce two output empty events. > > Be warned... Most people flipping RTS after write are trying to do > something like RS485 which has timing implications. There are > inexpensive > hardware solutions that can do a better job in such cases. > > The multiple output buffer observation may be a problem I'm observing > too. > Its just a little complicated to work out for all OS's and hardware. I > suspect the error is trivial when identified though. > > -- > Trent Jarvi > [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] > tjarvi at qbang.org > From ralf at lehmann.cc Tue Oct 17 07:32:12 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 17 Oct 2006 15:32:12 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <4534DB5C.3090600@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/84a01720/ralf-0007.vcf From ralf at lehmann.cc Wed Oct 18 15:27:33 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 23:27:33 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <4534DB5C.3090600@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> Message-ID: <45369C45.2090200@lehmann.cc> Ralf Lehmann wrote: Had it solved. In configure.in : line 464:case $JAVA_VERSION in 1.2*|1.3*|1.4*|1.5*|1.6*) i have added 1.6* because i use java-1.6-rc it works very stable with 1.6 so i think you could add 1.6* thanks > Thanks Arun, > so i could build a working jar. > > The "make install" failure of the rxtx-2.1-7r2-package i have solved. > > >> make install >> make all-am >> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >> Try `libtool --help --mode=install' for more information. >> > in the makefile RXTX_PATH and JHOME are undefined. > If i point them to a directory the install works. > I don't no why they are undefined the other java-specific variables are > correctly defined. > > > thanks ralf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061018/f56b1ecf/ralf-0007.vcf From tjarvi at qbang.org Thu Oct 19 07:21:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 19 Oct 2006 07:21:14 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <45369C45.2090200@lehmann.cc> References: <20061016083002.17461.qmail@server212.com> <4534DB5C.3090600@lehmann.cc> <45369C45.2090200@lehmann.cc> Message-ID: Thanks Ralf Looks like we could switch that logic to look for jdk 1.1 and older :) You might imagine thats come up a few times when I've least expected it. I'll put it in the next release. On Wed, 18 Oct 2006, Ralf Lehmann wrote: > Ralf Lehmann wrote: > > Had it solved. > > In configure.in : > line 464:case $JAVA_VERSION in > > 1.2*|1.3*|1.4*|1.5*|1.6*) > > i have added 1.6* because i use java-1.6-rc > > it works very stable with 1.6 so i think you could add 1.6* > > thanks > > > > > > >> Thanks Arun, >> so i could build a working jar. >> >> The "make install" failure of the rxtx-2.1-7r2-package i have solved. >> >> >>> make install >>> make all-am >>> make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' >>> make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' >>> libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory >>> Try `libtool --help --mode=install' for more information. >>> >> in the makefile RXTX_PATH and JHOME are undefined. >> If i point them to a directory the install works. >> I don't no why they are undefined the other java-specific variables are >> correctly defined. >> >> >> thanks ralf >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From rjcarr at gmail.com Fri Oct 20 14:22:11 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 13:22:11 -0700 Subject: [Rxtx] rxtx problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sat Oct 21 06:58:11 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 08:58:11 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: The native methods for the javax.comm package need to support your mac. As you know, some macs now have intel inside (all the newer ones). I think we need a more transparent way to support the download and install of the universal mac binaries. Recently, I used CVS to obtain the project, but I was unable to determine if the binaries were universal or not. The basic systemic issue, as I see it, is that we do not have a way to generate the binaries for all the platforms from a single source code entity running on one machine. This is not easy to do, but I think it should be possible. As I see it, we are supporting native methods for many platforms in an ad-hoc manner. A more centralized mechanism for doing a build would be very helpful. For example, XCODE really has a tough time building mixed library universal binaries on a PPC mac. I have yet to be able to crack this nut. Wouldn't it be nice if we could create binaries for all the platforms from one place (like a Linux box)? Just type Make and get binaries for everybody. Is anybody out there good at this type of cross-platform compilation? I know this is hard, but it should be possible... Thanks! - DL >I posted this on the Sun forums: > >http://forum.java.sun.com/thread.jspa?messageID=4431672 > >But basically the problem is this ... can I use the RXTX driver >(version 2.0-7pre2) with the Sun javax.comm packages (generic version >2.0.3) on my Mac (version OSX.4.8)? > >I've tried every combination of using the 2.0 version, 2.1 version, >RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing >seems to work. > >Everything seems to result in an: > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver >... >Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > >Using 2.0 I don't get any RXTX output, but using 2.1 I get this: > >Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > >Here's the full stack trace (same for 2.0 and 2.1): > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) > at BlackBox.main(Unknown Source) > Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink > at com.sun.comm.Unix.isDevLink(Native Method) > at com.sun.comm.PathBundle.add(PathBundle.java:108) > at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) > at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) > at BlackBox.main(Unknown Source) > >Can anyone provide any help? > >Thanks- >Robert >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Oct 21 08:59:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 08:59:43 -0600 (MDT) Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: > The basic systemic issue, as I see it, is that we do not have > a way to generate the binaries for all the platforms from > a single source code entity running on one machine. > > This is not easy to do, but I think it should be possible. > > As I see it, we are supporting native methods for many > platforms in an ad-hoc manner. A more centralized mechanism > for doing a build would be very helpful. > > For example, XCODE really has a tough time building mixed > library universal binaries on a PPC mac. I have yet to be > able to crack this nut. > > Wouldn't it be nice if we could create binaries for all the platforms > from one place (like a Linux box)? Just type Make and get binaries > for everybody. > > Is anybody out there good at this type of cross-platform compilation? > I know this is hard, but it should be possible... Hi Doug I can give this a shot in January. Having gone down the cross-compiler path before, the problem is that these are not testcases for gcc releases. It is an amazing feat to be releasing gcc that works for as many platforms as it does. This suggests that companies are testing gcc extensively internally. I've seen that Apple does for instance. I think it may be possible for Mac now. The trick will be looking at patches off head if things do not work out of the box and possibly making adjustments. It is not a one night effort to plan for. The problem child is going to be Microsoft's 64 bit binary formats [and windows CE]. I don't know if they crippled themselves with patents or there just isn't interest in the GCC community. I do not see 64 bit windows or WinCE support out of the box anytime in the future. Apple is doing the right things and we should reward them for it. I'm not going to reward MSFT for doing the wrong thing on my dime and time. Maybe someone else here will. That would be fine. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Oct 21 09:37:19 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 21 Oct 2006 11:37:19 -0400 Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Trent, I am really ignorant about such things, so please excuse my obvious and dumb question. But isn't there some kind of a compile farm on sourceforge that has our mind, in mind? Basically, I think we just need a build farm. People who are smarter than I am, about such things, write papers. Are these things just science projects gone bad? For example, has anyone tried Build Buddy: http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html Or the sourceforge build farm? http://sourceforge.net/docs/A05/en/#top This looks pretty complex, to me. But someone with good experience in this area may find it easy. Thanks! - Doug > > The basic systemic issue, as I see it, is that we do not have >> a way to generate the binaries for all the platforms from >> a single source code entity running on one machine. >> >> This is not easy to do, but I think it should be possible. >> >> As I see it, we are supporting native methods for many >> platforms in an ad-hoc manner. A more centralized mechanism >> for doing a build would be very helpful. >> >> For example, XCODE really has a tough time building mixed >> library universal binaries on a PPC mac. I have yet to be >> able to crack this nut. >> >> Wouldn't it be nice if we could create binaries for all the platforms >> from one place (like a Linux box)? Just type Make and get binaries >> for everybody. >> >> Is anybody out there good at this type of cross-platform compilation? >> I know this is hard, but it should be possible... > >Hi Doug > >I can give this a shot in January. Having gone down the cross-compiler >path before, the problem is that these are not testcases for gcc releases. >It is an amazing feat to be releasing gcc that works for as many platforms >as it does. This suggests that companies are testing gcc extensively >internally. I've seen that Apple does for instance. I think it may be >possible for Mac now. The trick will be looking at patches off head if >things do not work out of the box and possibly making adjustments. It is >not a one night effort to plan for. > >The problem child is going to be Microsoft's 64 bit binary formats [and >windows CE]. I don't know if they crippled themselves with patents or >there just isn't interest in the GCC community. I do not see 64 bit >windows or WinCE support out of the box anytime in the future. > >Apple is doing the right things and we should reward them for it. I'm not >going to reward MSFT for doing the wrong thing on my dime and time. Maybe >someone else here will. That would be fine. > >-- >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 Sat Oct 21 10:38:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 21 Oct 2006 10:38:37 -0600 (MDT) Subject: [Rxtx] Do we need a build farm? In-Reply-To: References: Message-ID: Hi Doug These build farms are more or less what most of us do on the corp side. They keep mainy people gainfully employed. They tend to be milk cows due to their complexity; something I wont have time to babysit. Maybe someone else will. The advantage comes with automatic testing. With rxtx.org we have testers :) but no open automatic tests. Even if we generate the unit tests and use the compile farms, you will be missing many niche targets we support already out of the toybox such as ARM Linux. And how will we get a loopback connection on these farms for any testing that makes sense? Having done some work in a build farm setting, I seriously doubt its the right solution here. On Sat, 21 Oct 2006, Dr. Douglas Lyon wrote: > Hi Trent, > I am really ignorant about such things, so please > excuse my obvious and dumb question. But isn't > there some kind of a compile farm on sourceforge that > has our mind, in mind? > > Basically, I think we just need a build farm. People > who are smarter than I am, about such things, write papers. > Are these things just science projects gone bad? > For example, has anyone tried Build Buddy: > http://www.usenix.org/events/usenix05/tech/freenix/full_papers/mills/mills_html/bb-freenix-paper.html > Or the sourceforge build farm? > http://sourceforge.net/docs/A05/en/#top > > This looks pretty complex, to me. But someone with good experience > in this area may find it easy. > > Thanks! > - Doug > > >> > The basic systemic issue, as I see it, is that we do not have >>> a way to generate the binaries for all the platforms from >>> a single source code entity running on one machine. >>> >>> This is not easy to do, but I think it should be possible. >>> >>> As I see it, we are supporting native methods for many >>> platforms in an ad-hoc manner. A more centralized mechanism >>> for doing a build would be very helpful. >>> >>> For example, XCODE really has a tough time building mixed >>> library universal binaries on a PPC mac. I have yet to be >>> able to crack this nut. >>> >>> Wouldn't it be nice if we could create binaries for all the platforms >>> from one place (like a Linux box)? Just type Make and get binaries >>> for everybody. >>> >>> Is anybody out there good at this type of cross-platform compilation? >>> I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 11:11:17 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 10:11:17 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP site you had links for both PPC and Intel, but they linked to the same place because they were now universal? Yes, I just double checked, the README says: "These are universal binaries. Both directories are the same" So maybe I'm missing something? Do you mean specifically for the 2.0 release? But back on topic ... has anyone used the rxtx driver with the javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for some guidance. Thanks- Robert PS -- I'm using the gnu.io packages right now and everything is working fine, so my setup isn't too bad, but I'd still like to use the javax.comm packages if possible (no offense). On 10/21/06, Trent Jarvi wrote: > > The basic systemic issue, as I see it, is that we do not have > > a way to generate the binaries for all the platforms from > > a single source code entity running on one machine. > > > > This is not easy to do, but I think it should be possible. > > > > As I see it, we are supporting native methods for many > > platforms in an ad-hoc manner. A more centralized mechanism > > for doing a build would be very helpful. > > > > For example, XCODE really has a tough time building mixed > > library universal binaries on a PPC mac. I have yet to be > > able to crack this nut. > > > > Wouldn't it be nice if we could create binaries for all the platforms > > from one place (like a Linux box)? Just type Make and get binaries > > for everybody. > > > > Is anybody out there good at this type of cross-platform compilation? > > I know this is hard, but it should be possible... > > Hi Doug > > I can give this a shot in January. Having gone down the cross-compiler > path before, the problem is that these are not testcases for gcc releases. > It is an amazing feat to be releasing gcc that works for as many platforms > as it does. This suggests that companies are testing gcc extensively > internally. I've seen that Apple does for instance. I think it may be > possible for Mac now. The trick will be looking at patches off head if > things do not work out of the box and possibly making adjustments. It is > not a one night effort to plan for. > > The problem child is going to be Microsoft's 64 bit binary formats [and > windows CE]. I don't know if they crippled themselves with patents or > there just isn't interest in the GCC community. I do not see 64 bit > windows or WinCE support out of the box anytime in the future. > > Apple is doing the right things and we should reward them for it. I'm not > going to reward MSFT for doing the wrong thing on my dime and time. Maybe > someone else here will. That would be fine. > > -- > 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 Sun Oct 22 11:39:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 22 Oct 2006 13:39:12 -0400 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: Hi Bob, I am working on a very experimental reference implementation and sure could use some help with it. http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp Has a testing program (not intel mac tested). Lets chat off-list (if you can stand being a beta tester). Regards, - DL >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP >site you had links for both PPC and Intel, but they linked to the same >place because they were now universal? Yes, I just double checked, >the README says: > >"These are universal binaries. Both directories are the same" > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > >But back on topic ... has anyone used the rxtx driver with the >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for >some guidance. > >Thanks- >Robert > >PS -- I'm using the gnu.io packages right now and everything is >working fine, so my setup isn't too bad, but I'd still like to use the >javax.comm packages if possible (no offense). > >On 10/21/06, Trent Jarvi wrote: >> > The basic systemic issue, as I see it, is that we do not have >> > a way to generate the binaries for all the platforms from >> > a single source code entity running on one machine. >> > >> > This is not easy to do, but I think it should be possible. >> > >> > As I see it, we are supporting native methods for many >> > platforms in an ad-hoc manner. A more centralized mechanism >> > for doing a build would be very helpful. >> > >> > For example, XCODE really has a tough time building mixed >> > library universal binaries on a PPC mac. I have yet to be >> > able to crack this nut. >> > >> > Wouldn't it be nice if we could create binaries for all the platforms >> > from one place (like a Linux box)? Just type Make and get binaries >> > for everybody. >> > >> > Is anybody out there good at this type of cross-platform compilation? >> > I know this is hard, but it should be possible... >> >> Hi Doug >> >> I can give this a shot in January. Having gone down the cross-compiler >> path before, the problem is that these are not testcases for gcc releases. >> It is an amazing feat to be releasing gcc that works for as many platforms >> as it does. This suggests that companies are testing gcc extensively >> internally. I've seen that Apple does for instance. I think it may be >> possible for Mac now. The trick will be looking at patches off head if >> things do not work out of the box and possibly making adjustments. It is >> not a one night effort to plan for. >> >> The problem child is going to be Microsoft's 64 bit binary formats [and >> windows CE]. I don't know if they crippled themselves with patents or >> there just isn't interest in the GCC community. I do not see 64 bit >> windows or WinCE support out of the box anytime in the future. >> >> Apple is doing the right things and we should reward them for it. I'm not >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe >> someone else here will. That would be fine. >> >> -- >> 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 rjcarr at gmail.com Sun Oct 22 21:40:24 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Sun, 22 Oct 2006 20:40:24 -0700 Subject: [Rxtx] rxtx problems on mac In-Reply-To: References: Message-ID: You've got my attention, let me know what you'd like me to do. On 10/22/06, Dr. Douglas Lyon wrote: > Hi Bob, > I am working on a very experimental reference implementation and > sure could use some help with it. > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.PortTest.jnlp > Has a testing program (not intel mac tested). > > Lets chat off-list (if you can stand being a beta tester). > Regards, > - DL > > > >Sorry, I should have mentioned I have a PPC Mac. I thought on the FTP > >site you had links for both PPC and Intel, but they linked to the same > >place because they were now universal? Yes, I just double checked, > >the README says: > > > >"These are universal binaries. Both directories are the same" > > > >So maybe I'm missing something? Do you mean specifically for the 2.0 release? > > > >But back on topic ... has anyone used the rxtx driver with the > >javax.comm packages on a (specifically PPC) Mac? If so I'm hoping for > >some guidance. > > > >Thanks- > >Robert > > > >PS -- I'm using the gnu.io packages right now and everything is > >working fine, so my setup isn't too bad, but I'd still like to use the > >javax.comm packages if possible (no offense). > > > >On 10/21/06, Trent Jarvi wrote: > >> > The basic systemic issue, as I see it, is that we do not have > >> > a way to generate the binaries for all the platforms from > >> > a single source code entity running on one machine. > >> > > >> > This is not easy to do, but I think it should be possible. > >> > > >> > As I see it, we are supporting native methods for many > >> > platforms in an ad-hoc manner. A more centralized mechanism > >> > for doing a build would be very helpful. > >> > > >> > For example, XCODE really has a tough time building mixed > >> > library universal binaries on a PPC mac. I have yet to be > >> > able to crack this nut. > >> > > >> > Wouldn't it be nice if we could create binaries for all the platforms > >> > from one place (like a Linux box)? Just type Make and get binaries > >> > for everybody. > >> > > >> > Is anybody out there good at this type of cross-platform compilation? > >> > I know this is hard, but it should be possible... > >> > >> Hi Doug > >> > >> I can give this a shot in January. Having gone down the cross-compiler > >> path before, the problem is that these are not testcases for gcc releases. > >> It is an amazing feat to be releasing gcc that works for as many platforms > >> as it does. This suggests that companies are testing gcc extensively > >> internally. I've seen that Apple does for instance. I think it may be > >> possible for Mac now. The trick will be looking at patches off head if > >> things do not work out of the box and possibly making adjustments. It is > >> not a one night effort to plan for. > >> > >> The problem child is going to be Microsoft's 64 bit binary formats [and > >> windows CE]. I don't know if they crippled themselves with patents or > >> there just isn't interest in the GCC community. I do not see 64 bit > >> windows or WinCE support out of the box anytime in the future. > >> > >> Apple is doing the right things and we should reward them for it. I'm not > >> going to reward MSFT for doing the wrong thing on my dime and time. Maybe > >> someone else here will. That would be fine. > >> > >> -- > >> 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 ralf at lehmann.cc Tue Oct 24 05:55:05 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 13:55:05 +0200 Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453DFF19.2060403@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/643177cf/ralf-0007.vcf From ali.salehi at epfl.ch Tue Oct 24 09:29:20 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 17:29:20 +0200 (CEST) Subject: [Rxtx] RXTX problem on Intel Mac 10.4.8 Message-ID: <49446.128.178.156.63.1161703760.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I have the RXTXcomm.jar, librxtxSerial.jnilib files copied in the /Library/Java/Extensions/ directory. My application should connect to the /dev/tty.PL2303-0000101D device (serial-usb adaptor). [java] Stable Library [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 [java] WARN [2006-10-24 16:50:24,963] [VSensorLoader-Thread0] (SerialWrapper.java:85) - Serial port wrapper couldn't connect to serial port : /dev/tty.PL2303-0000101D [java] gsn.wrappers.general.SerialConnectionException: Unknown Application [java] at SerialWrapper$SerialConnection.openConnection(SerialWrapper.java:153) Any ideas ? Thanks in advance for your help. AliS ps : java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From ralf at lehmann.cc Tue Oct 24 14:10:02 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Tue, 24 Oct 2006 22:10:02 +0200 (MEST) Subject: [Rxtx] continuous loop if writing to a port without a connected device Message-ID: <453E731A.3040804@lehmann.cc> Hi, i use RXTX-2.1-7 to drive a epson TMT-88 and it works. But if the printer is disconnected or switched of i run into a continuous loop. I do a little debugging and the debugger point me to RXTXPort.nativeDrain RXTXPort$SerialOutputStream.flush:1209 why i get no Exception or event that rxtx flush timed out? thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: Deleted:ralf.vcf Type: text/x-moz-deleted Size: 201 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0007.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061024/e9ee0d24/ralf-0007.vcf From naranjo.manuel at gmail.com Tue Oct 24 14:26:05 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 24 Oct 2006 17:26:05 -0300 Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453E731A.3040804@lehmann.cc> References: <453E731A.3040804@lehmann.cc> Message-ID: <453E76DD.1080405@gmail.com> Hi, I think you are missing something. You need to tell RXTX to advice you about different events. Check the methods that start with notifyOn* and add an event listener to the serial port. Cheers, Manuel pd: You have send the email twice, I don't know if it was made on porpoise or not, but can be considerer as something bad :D try not to do it again. > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > > > ------------------------------------------------------------------------ > From ali.salehi at epfl.ch Tue Oct 24 14:50:51 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Tue, 24 Oct 2006 22:50:51 +0200 (CEST) Subject: [Rxtx] RXTX PortInUse Exception. Message-ID: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Dear friends, I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib files /Library/Java/Extensions/ directory (I also executed the fixperm.sh script). My java application should connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). But I'm always getting PortInUseexception when I call the openConnection. I checked the uucp directory, there is no file there. I also tried to execute the program under the root user, rebooting, but still the same exception. Also the isCurrentlyOwned( ) method always returns false. Any ideas ? [java] ========================================= [java] Native lib Version = RXTX-2.1-7 [java] Java lib Version = RXTX-2.1-7 Thanks in advance for your help. AliS PS - JDK 1.5 update 06 From tjarvi at qbang.org Tue Oct 24 17:15:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:15:41 -0600 (MDT) Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: On Tue, 24 Oct 2006, Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > Hi Ali I suspect one of two things. It is possible that there is a problem with the lockfiles. I think that may be going to /var/lock not uucp. The other possibility is OPEN_EXCL is failing meaning another instance or application already has an exclusive lock via an ioctl [C code]. With Mac, you can compile with -DDISABLE_LOCKFILES passed to the C compiler. The OPEN_EXCL should do all you need. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Oct 24 17:25:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 24 Oct 2006 17:25:13 -0600 (MDT) Subject: [Rxtx] continuous loop if writing to a port without a connected device In-Reply-To: <453DFF19.2060403@lehmann.cc> References: <453DFF19.2060403@lehmann.cc> Message-ID: On Tue, 24 Oct 2006, Ralf Lehmann wrote: > Hi, > > i use RXTX-2.1-7 to drive a epson TMT-88 and it works. > > But if the printer is disconnected or switched of i run into a > continuous loop. > I do a little debugging and the debugger point me to > RXTXPort.nativeDrain > RXTXPort$SerialOutputStream.flush:1209 > > why i get no Exception or event that rxtx flush timed out? > > thanks > ralf > > flush will not timeout. It will wait until all data has been transmitted then return. At least thats how it should behave. Perhaps its getting an error like EWOULDBLOCK and the native code is not catching it. Perhaps you can watch for CD [carrier detect] events to know when your printer is turned off? -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Tue Oct 24 17:32:29 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 24 Oct 2006 19:32:29 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: <453EA28D.6010408@suespammers.org> Trent Jarvi wrote: > I suspect one of two things. It is possible that there is a problem with > the lockfiles. I think that may be going to /var/lock not uucp. The > other possibility is OPEN_EXCL is failing meaning another instance or > application already has an exclusive lock via an ioctl [C code]. the lock files are in /var/lock on my powerbook. remember that the directory needs to be root/uucp, perms of 755, and any user who might need a lock needs to be in the uucp group richard From ajmas at sympatico.ca Tue Oct 24 18:02:46 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 24 Oct 2006 20:02:46 -0400 Subject: [Rxtx] RXTX PortInUse Exception. In-Reply-To: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> References: <15801.83.219.104.23.1161723051.squirrel@icsil1mail.epfl.ch> Message-ID: Hi, I resolved this issue by grabbing the code destined for 2.1.8, from CVS, which does away with file locks MacOS X. Andre On 24-Oct-06, at 16:50 , Ali Salehi wrote: > Dear friends, > I want to use rxtx (2.1.7-rc2;binary) to connect to the serial > port on > an intel mac mini(10.4.8). I copied the RXTXcomm.jar, > librxtxSerial.jnilib > files /Library/Java/Extensions/ directory (I also > executed the fixperm.sh script). My java application should > connect to the /dev/tty.PL2303-0000101D (a serial-usb adaptor). > But I'm always getting PortInUseexception when I call the > openConnection. > I checked the uucp directory, there is no file there. > I also tried to execute the program under the root user, rebooting, > but still the same exception. > Also the isCurrentlyOwned( ) method always returns false. > > > Any ideas ? > > [java] ========================================= > [java] Native lib Version = RXTX-2.1-7 > [java] Java lib Version = RXTX-2.1-7 > > > Thanks in advance for your help. > > AliS > PS - JDK 1.5 update 06 > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ali.salehi at epfl.ch Wed Oct 25 01:22:28 2006 From: ali.salehi at epfl.ch (Ali Salehi) Date: Wed, 25 Oct 2006 09:22:28 +0200 (CEST) Subject: [Rxtx] PortInUse Exception Message-ID: <49410.128.178.156.63.1161760948.squirrel@icsil1mail.epfl.ch> Hi, I resolved the issue by fixing the fixperm.sh file :-) The fixperm.sh(in the release) still uses the uucp directory for locks while the library is looks for the locks in the /var/lock Thanks for your help, Best, AliS ************************************************************** Ali Salehi, LSIR - Distributed Information Systems Laboratory EPFL-IC-IIF-LSIR, B?timent BC, Station 14, CH-1015 Lausanne, Switzerland. http://lsirwww.epfl.ch/ email: ali.salehi at epfl.ch Tel: +41-21-6936656 Fax: +41-21-6938115 From vesaas at hotmail.com Fri Oct 27 14:48:24 2006 From: vesaas at hotmail.com (Tarjei Rommetveit) Date: Fri, 27 Oct 2006 20:48:24 +0000 Subject: [Rxtx] Data drop-outs and priority in Windows XP Message-ID: Hello, I am developing a console which interacts with a datalogger at 115200 b/s. One of the options for the console is to silently listen to the bus and process incoming data. My problem is that data dropouts occur randomly. This may happen after 10 seconds as well as after 10 minutes; there seem to be no logic in when the dropouts occur except that they occur more often when the cpu is more busy with e.g. other programs. But the dropouts may also occur even if the cpu uses well below 10% of its capacity. I have found one solution to the problem: right-click on the process after startup (after ctrl-alt-delete) and set it to real time application (highest priority). When I set the thread to max priority in java (MAX_PRIORITY) I only obtain 10, while I think real-time operations are in the range from 15 to 30 or something. Primary question: Is it possible to set the process to a real-time-application inside java (so that windows xp recognizes it as a real-time operation)? Secondary question: Have anobody else experienced/solved similar problems without setting the priority to real-time? And if possible, how? Thanks in advance Terry _________________________________________________________________ MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million låter From tjarvi at qbang.org Sun Oct 29 07:38:41 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 29 Oct 2006 07:38:41 -0700 (MST) Subject: [Rxtx] Data drop-outs and priority in Windows XP In-Reply-To: References: Message-ID: On Fri, 27 Oct 2006, Tarjei Rommetveit wrote: > Hello, > > I am developing a console which interacts with a datalogger at 115200 b/s. > One of the options for the console is to silently listen to the bus and > process incoming data. My problem is that data dropouts occur randomly. This > may happen after 10 seconds as well as after 10 minutes; there seem to be no > logic in when the dropouts occur except that they occur more often when the > cpu is more busy with e.g. other programs. But the dropouts may also occur > even if the cpu uses well below 10% of its capacity. > > I have found one solution to the problem: right-click on the process after > startup (after ctrl-alt-delete) and set it to real time application (highest > priority). When I set the thread to max priority in java (MAX_PRIORITY) I > only obtain 10, while I think real-time operations are in the range from 15 > to 30 or something. > > Primary question: Is it possible to set the process to a > real-time-application inside java (so that windows xp recognizes it as a > real-time operation)? > > Secondary question: Have anobody else experienced/solved similar problems > without setting the priority to real-time? And if possible, how? > Hi Tarjei Nice observation about the 'realtime' priority setting. I tried it Friday for ome unrelated problems I was looking at. It didn't solve my problem but it may help others. By ignoring things like interrupts from keyboards and serial ports, operating systems are able to better optimize their schedualing for complex GUIs. So there will always be a conflict in directions. Some will want near realtime performance for instrument and machine control or hybrid communication protocols while others will want their web browsers to not gitter when they use the scroll button. Operating systems like to disable the serial port interrupts and push it off in the schedualing as much as possible. The serial port happens to be the most common terminal on embeded systems in Linux/BSD so it will presumaly hold a slightly higher position there. I've not seen a solution yet. One thing that may be of interest is that you can also play with the input buffer on windows. Disabling that may improve bitbang types of operations. Control Panel->system->devices... There could also be slowdowns in rxtx that we are not aware of. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Oct 30 11:45:56 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 13:45:56 -0500 Subject: [Rxtx] Missing Java files? Message-ID: <9EBB97BA-0882-4A0C-84B9-4B30AF56AC03@sympatico.ca> Hi, I went and got the source code from CVS, but there seems to be a number of Java classes missing. This is what I have: find . -name "*.java" -print ./contrib/DSR-workaround.java ./contrib/LeakTest1.java ./contrib/PortTest.java ./contrib/SimpleRead.java ./contrib/SimpleSnuV1.java ./contrib/SNComHandler.java ./contrib/Test.java ./contrib/TestMonitorThread.java ./src/Configure.java ./src/LPRPort.java ./src/RXTXCommDriver.java ./src/RXTXPort.java ./src/RXTXVersion.java ./src/UnSupportedLoggerException.java ./src/Zystem.java Where are the other Java classes meant to be? Andre From ajmas at sympatico.ca Mon Oct 30 13:52:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 30 Oct 2006 15:52:13 -0500 Subject: [Rxtx] Added CVS instructions to Wiki Message-ID: <5DDE14F9-A3D4-4367-B101-9AC88D16A718@sympatico.ca> Hi, Noticing that the CVS instructions on the main site looked a little dated, IMHO, I decided to add a page to the Wiki with updated instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code If you any improvements to make to them, feel free to do so. Andre From tjarvi at qbang.org Mon Oct 30 17:28:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 30 Oct 2006 17:28:08 -0700 (MST) Subject: [Rxtx] gentoo release at last! In-Reply-To: References: Message-ID: On Mon, 30 Oct 2006, [ISO-8859-2] Ill?s P?l Zolt?n wrote: > > Hi! > > Good news! > Just wanted to let you know that finally latest release, > which I wrote you previously, it has gone into gentoo portage! > > > Bye, > Paul Thanks Paul, I'll forward this to the rxtx mail-list so others know. -- Trent Jarvi tjarvi at qbang.org From rjcarr at gmail.com Fri Oct 20 14:17:41 2006 From: rjcarr at gmail.com (Robert J. Carr) Date: Fri, 20 Oct 2006 20:17:41 -0000 Subject: [Rxtx] problems on mac Message-ID: I posted this on the Sun forums: http://forum.java.sun.com/thread.jspa?messageID=4431672 But basically the problem is this ... can I use the RXTX driver (version 2.0-7pre2) with the Sun javax.comm packages (generic version 2.0.3) on my Mac (version OSX.4.8)? I've tried every combination of using the 2.0 version, 2.1 version, RXTXcomm.jar, jcl.jar, comm.jar, -Djava.library.path, etc ... nothing seems to work. Everything seems to result in an: java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver ... Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink Using 2.0 I don't get any RXTX output, but using 2.1 I get this: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Here's the full stack trace (same for 2.0 and 2.1): java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:109) at BlackBox.main(Unknown Source) Exception in thread "main" java.lang.UnsatisfiedLinkError: isDevLink at com.sun.comm.Unix.isDevLink(Native Method) at com.sun.comm.PathBundle.add(PathBundle.java:108) at com.sun.comm.PlatformPortBundle.(PlatformPortBundle.java:44) at javax.comm.CommPortIdentifier.(CommPortIdentifier.java:138) at BlackBox.main(Unknown Source) Can anyone provide any help? Thanks- Robert From lyon at docjava.com Sun Oct 1 04:25:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 06:25:37 -0400 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: Hi Trent, Is it your experience that the JVM will not die, under these circumstances, even if System.exit(0) is called from another thread? Thanks! - DL >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 >> > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 06:43:27 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 08:43:27 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is the swing version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp 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); } And here is the AWT version: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.awt.RunSerialPortPanel.jnlp public static void main(String[] args) { final ClosableFrame cf = new ClosableFrame(); cf.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } I must say that I find almost identical code strewn about in a system to be one of the famous bad smells in code. Can anyone think of a way around this? I hate to mention "macros" in mixed company! Regards, - Doug >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 >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From j.a.horsmeier at wanadoo.nl Sun Oct 1 07:05:13 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 15:05:13 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> > 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); > } Just a small remark: why does that ClosableJFrame need a 'pack()' both in the setup and in the inner class object? kind regards, Jos From lyon at docjava.com Sun Oct 1 07:23:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:23:39 -0400 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> References: <0ae701c6e55a$3ba08230$0a01a8c0@CALVIN> Message-ID: Hi Jos, You have sharp eyes, that is just plain sloppy code, and it works well with just one pack. - Doug > > 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); >> } > >Just a small remark: why does that ClosableJFrame need a 'pack()' both in >the setup and in the inner class object? > >kind regards, > >Jos > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Oct 1 07:36:46 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 01 Oct 2006 09:36:46 -0400 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!! Thanks! > >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. You can check the value of the SerialPortBean against the port-specific business logic that your application requires. Should the SerialPortBean violate the limits of the settings, you can inform the user of these limits or, if you really want fancy, use a veto design pattern. Hmm. What could we do to implement that in a bean? For example, here is the FlowControlBean: public final class FlowControlBean implements Serializable { private String name; private int intValue; private final static int FLOWCONTROL_NONE = 0; /** * RTS/CTS flow control on input. */ private final static int FLOWCONTROL_RTSCTS_IN = 1; /** * RTS/CTS flow control on output. */ private final static int FLOWCONTROL_RTSCTS_OUT = 2; /** * XON/XOFF flow control on input. */ private final static int FLOWCONTROL_XONXOFF_IN = 4; /** * XON/XOFF flow control on output. */ private final static int FLOWCONTROL_XONXOFF_OUT = 8; public final static FlowControlBean none = new FlowControlBean("None", FLOWCONTROL_NONE); public final static FlowControlBean rtsCts = new FlowControlBean("RTS/CTS", FLOWCONTROL_RTSCTS_IN | FLOWCONTROL_RTSCTS_OUT); public final static FlowControlBean xonXoff = new FlowControlBean("XOn/XOff", FLOWCONTROL_XONXOFF_IN | FLOWCONTROL_XONXOFF_OUT); private static FlowControlBean flowControlBeans[] = new FlowControlBean[]{ none, rtsCts, xonXoff }; private FlowControlBean(String name, int intValue) { this.name = name; this.intValue = intValue; } public String toString() { return name; } public boolean equals(Object o){ return getIntValue() == (((FlowControlBean)o).getIntValue()); } public String getName() { return name; } public int getIntValue() { return intValue; } /** * Use Singleton Design Pattern to ensure consistency * * @return all possible flow control beans for an interface. */ public static FlowControlBean[] getFlowControlBeans() { return flowControlBeans; } } > >*) 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) I hear you. The FlowControlBean is not as general as it could be. Input flow control could be different from output flow control. I am not happy with the idea that the FlowControlBean assumes they are the same, but I have not cleared up the design issue in my own mind. Note that by creating BEANS like this, we become GUI agnostic, which makes the keeping of a SWING vs an AWT version (or SWT if we try it) a little easier to maintain. I did not put any listeners in, or any extra design patterns (i.e., I sought to create a simple example). However, with feature creep, I can't see out simplicity can be kept. > >*) 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. This is a job for the BaudRateBean! public final class BaudRateBean implements Serializable { private int value = 300; private String name = "300"; public static final BaudRateBean br00300 = new BaudRateBean(300, "300"); public static final BaudRateBean br01200 = new BaudRateBean(1200, "1200"); public static final BaudRateBean br02400 = new BaudRateBean(2400, "2400"); public static final BaudRateBean br04800 = new BaudRateBean(4800, "4800"); public static final BaudRateBean br09600 = new BaudRateBean(9600, "9600"); public static final BaudRateBean br19200 = new BaudRateBean(19200, "19200"); public static final BaudRateBean br57600 = new BaudRateBean(57600, "57600"); private BaudRateBean(int value, String name) { this.value = value; this.name = name; } public static BaudRateBean[] getBaudRateBeans() { return new BaudRateBean[]{ br00300, br01200, br02400, br04800, br09600, br19200, br57600 }; } public String toString() { return getName(); } public String getName() { return name; } public int getValue() { return value; } public boolean equals(Object o){ return getValue() == (((BaudRateBean)o).getValue()); } public static void main(String[] args) { ClosableFrame cf = new ClosableFrame(); cf.setLayout(new FlowLayout()); BaudRateBean items[] = getBaudRateBeans(); cf.add(new RunComboBox(items) { public void run() { System.out.println(getValue()); } }); cf.setVisible(true); } } > >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. GO 4 IT! Thanks! - Doug > >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 j.a.horsmeier at wanadoo.nl Sun Oct 1 08:14:34 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Sun, 1 Oct 2006 16:14:34 +0200 Subject: [Rxtx] gui v1.1, example of use SWING vs. AWT In-Reply-To: Message-ID: <0b3101c6e563$f13a7160$0a01a8c0@CALVIN> Hi Doug, you wrote: > You have sharp eyes, that is just plain sloppy code, and it > works well with just one pack. Ah, ok; nitpicking is in my genes hence my remark ;-) kind regards, Jos From joachim at buechse.de Sun Oct 1 11:03:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 1 Oct 2006 19:03:34 +0200 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: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> I can send a memory dump of a VM thread blocked in write. But to reproduce it, you would need a device that can be made to stop responding... Best regards, Joachim On 30.09.2006, at 14:41, 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 lyon at docjava.com Mon Oct 2 04:52:09 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 06:52:09 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, Let me see if I can understand the issue: 1. You call close on the serial port. 2. The kernel blocks the invoking java thread. 3. Time-out software that runs in an independent thread continues to call system.exit(0), but the JVM does not quit. Does that correctly summarize the situation that you are seeing? Thanks! - Doug >I can send a memory dump of a VM thread blocked in write. But to? >reproduce it, you would need a device that can be made to stop? >responding... > >Best regards, >Joachim > > >On 30.09.2006, at 14:41, 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 > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Oct 2 07:14:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 2 Oct 2006 15:14:09 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Situation 1 as you described: Depending on the exact details of the application, you will see windows closing or not. But you can always see the VM treads living an afterlive with status zombie. Another (constructed!) situation is this: The VM finalizer thread calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which calls nativeClose() which blocks. Hence the finalizer thread is dead- locked and no more object finalization takes place. This would only happen if: - application performs a write, then releases all references of the port object - device stops responding after the "writer" has returned from write, but before all data could actually be delivered - close tries to flush (or all writes are followed by a flush executed by a different native thread as in RXTX which blocks close) Regards, Joachim On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > Hi Joachim, > > Let me see if I can understand the issue: > 1. You call close on the serial port. > 2. The kernel blocks the invoking java thread. > 3. Time-out software that runs in an independent thread > continues to call system.exit(0), but the JVM does not quit. > > Does that correctly summarize the situation that you are seeing? > > Thanks! > - Doug > > >> I can send a memory dump of a VM thread blocked in write. But to >> reproduce it, you would need a device that can be made to stop >> responding... >> >> Best regards, >> Joachim >> >> >> On 30.09.2006, at 14:41, 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Mon Oct 2 13:01:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 02 Oct 2006 15:01:03 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: Hi Joachim, It sounds like we need to modify the specification on the close statement in order to address your concern, from: 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(); } To: 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. Associated OutputStream * instances are not flushed. */ void close(); } Does this address your concern? Thanks! - Doug >Situation 1 as you described: Depending on the exact details of the? >application, you will see windows closing or not. But you can always? >see the VM treads living an afterlive with status zombie. > >Another (constructed!) situation is this: The VM finalizer thread? >calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which? >calls nativeClose() which blocks. Hence the finalizer thread is dead- >locked and no more object finalization takes place. This would only? >happen if: >- application performs a write, then releases all references of the? >port object >- device stops responding after the "writer" has returned from write,? >but before all data could actually be delivered >- close tries to flush (or all writes are followed by a flush? >executed by a different native thread as in RXTX which blocks close) > >Regards, >Joachim > >On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> Let me see if I can understand the issue: >> 1. You call close on the serial port. >> 2. The kernel blocks the invoking java thread. >> 3. Time-out software that runs in an independent thread >> continues to call system.exit(0), but the JVM does not quit. >> >> Does that correctly summarize the situation that you are seeing? >> >> Thanks! >> - Doug >> >> >>> I can send a memory dump of a VM thread blocked in write. But to >>> reproduce it, you would need a device that can be made to stop >>> responding... >>> >>> Best regards, >>> Joachim >>> >>> >>> On 30.09.2006, at 14:41, 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 >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From kaha at gmx.de Mon Oct 2 12:06:10 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 20:06:10 +0200 Subject: [Rxtx] Weird printer problem: Message-ID: <45215512.1060501@gmx.de> Hi there, I'm a fresh user of rxtx, after finding that the Sun implemetation didn't work for me on linux. rxtx does a better job, but there are still some problems... gnu.io.LPRPort.writeArray() causes an exception when trying to print a little more text: Caused by: java.io.IOException: No space left on device in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:286) at de.hackemesser.commconnector.CommPortConnectionImpl.write(CommPortConnectionImpl.java:320) device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) How do I solve that? Kind regards, Kai From gergg at cox.net Mon Oct 2 13:19:26 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 14:19:26 -0500 Subject: [Rxtx] Weird printer problem: In-Reply-To: <45215512.1060501@gmx.de> References: <45215512.1060501@gmx.de> Message-ID: <4521663E.7090805@cox.net> Kai Hackemesser wrote: > device is an old POD printer at /dev/lp0. Using latest rxtx binaries (2.1.7) > How do I solve that? I'd guess that there is not a device named /dev/lp0 and that instead, a plain file has been created there, and you are appending to it, and filling up the root partition. What does ls -l /dev/lp0 show you for output? Gregg Wonderly From gergg at cox.net Mon Oct 2 09:18:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 02 Oct 2006 10:18:50 -0500 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <45212DDA.105@cox.net> Joachim Buechse wrote: > I can send a memory dump of a VM thread blocked in write. But to > reproduce it, you would need a device that can be made to stop > responding... Connect a serial loopback cable without HW flow control enabled, and then just call read with the port configured to use HW flow control. Gregg Wonderly From kaha at gmx.de Mon Oct 2 13:59:05 2006 From: kaha at gmx.de (Kai Hackemesser) Date: Mon, 02 Oct 2006 21:59:05 +0200 Subject: [Rxtx] Weird printer problem: In-Reply-To: <4521663E.7090805@cox.net> References: <45215512.1060501@gmx.de> <4521663E.7090805@cox.net> Message-ID: <45216F89.6010602@gmx.de> Gregg Wonderly schrieb: > Kai Hackemesser wrote: > >> device is an old POS printer at /dev/lp0. Using latest rxtx binaries (2.1.7) >> How do I solve that? >> > > I'd guess that there is not a device named /dev/lp0 and that instead, a plain > file has been created there, and you are appending to it, and filling up the > root partition. Hi Greg, The device is there and accessible, it is already accepting writes into the output stream. But my application may push data faster than the device can stand. So it gets this 'No space left' problem and I catch the IO exception. I would like to avoid that. Ciao! Kai From joachim at buechse.de Tue Oct 3 02:50:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 3 Oct 2006 10:50:32 +0200 Subject: [Rxtx] Definition for close() In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> Message-ID: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> I'd prefer a more prosy a change along the lines: --- Closes this communications port. All PortOwnershipListeners will be notified of this change of ownership. Further method calls on this object will throw IllegalStateException. Further calls on the associated InputStream or OutputStream will throw IOException.

Close does not block. Undelivered data is discarded. Blocked read and write operations are aborted if the underlying operating systems supports an IO abort mechanism. To await the delivery of undelivered data call OutputStream.flush() or OutputStream.close() before calling Port.close(). --- Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > Hi Joachim, > It sounds like we need to modify the specification on the close > statement > in order to address your concern, from: > 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(); > } > > To: > 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. > Associated OutputStream > * instances are not flushed. > */ > void close(); > } > > Does this address your concern? > Thanks! > - Doug > >> Situation 1 as you described: Depending on the exact details of the >> application, you will see windows closing or not. But you can always >> see the VM treads living an afterlive with status zombie. >> >> Another (constructed!) situation is this: The VM finalizer thread >> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >> calls nativeClose() which blocks. Hence the finalizer thread is dead- >> locked and no more object finalization takes place. This would only >> happen if: >> - application performs a write, then releases all references of the >> port object >> - device stops responding after the "writer" has returned from write, >> but before all data could actually be delivered >> - close tries to flush (or all writes are followed by a flush >> executed by a different native thread as in RXTX which blocks close) >> >> Regards, >> Joachim >> >> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> Let me see if I can understand the issue: >>> 1. You call close on the serial port. >>> 2. The kernel blocks the invoking java thread. >>> 3. Time-out software that runs in an independent thread >>> continues to call system.exit(0), but the JVM does not quit. >>> >>> Does that correctly summarize the situation that you are seeing? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I can send a memory dump of a VM thread blocked in write. But to >>>> reproduce it, you would need a device that can be made to stop >>>> responding... >>>> >>>> Best regards, >>>> Joachim >>>> >>>> >>>> On 30.09.2006, at 14:41, 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 >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 04:31:01 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 03 Oct 2006 06:31:01 -0400 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: Hi All, I have no objection to Joachim's suggestion. Are we all aboard with the changes? Thanks! - DL >I'd prefer a more prosy a change along the lines: > >--- >Closes this communications port. All PortOwnershipListeners will be? >notified of this change of ownership. Further method calls on this? >object will throw IllegalStateException. Further calls on the? >associated InputStream or OutputStream will throw IOException. >

>Close does not block. Undelivered data is discarded. Blocked read and? >write operations are aborted if the underlying operating systems? >supports an IO abort mechanism. To await the delivery of undelivered? >data call OutputStream.flush() or OutputStream.close() before calling? >Port.close(). >--- > >Best regards, >Joachim >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 02.10.2006, at 21:01, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> It sounds like we need to modify the specification on the close? >> statement >> in order to address your concern, from: >> 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(); >> } >> >> To: >> 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. >> Associated OutputStream >> * instances are not flushed. >> */ >> void close(); >> } >> >> Does this address your concern? >> Thanks! >> - Doug >> >>> Situation 1 as you described: Depending on the exact details of the >>> application, you will see windows closing or not. But you can always >>> see the VM treads living an afterlive with status zombie. >>> >>> Another (constructed!) situation is this: The VM finalizer thread >>> calls RXTXPort.finalize() wich in turn calls RXTXPort.close() which >>> calls nativeClose() which blocks. Hence the finalizer thread is dead- >>> locked and no more object finalization takes place. This would only >>> happen if: >>> - application performs a write, then releases all references of the >>> port object >>> - device stops responding after the "writer" has returned from write, >>> but before all data could actually be delivered >>> - close tries to flush (or all writes are followed by a flush >>> executed by a different native thread as in RXTX which blocks close) >>> >>> Regards, >>> Joachim >>> >>> On 02.10.2006, at 12:52, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> Let me see if I can understand the issue: >>>> 1. You call close on the serial port. >>>> 2. The kernel blocks the invoking java thread. >>>> 3. Time-out software that runs in an independent thread >>>> continues to call system.exit(0), but the JVM does not quit. >>>> >>>> Does that correctly summarize the situation that you are seeing? > >>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> I can send a memory dump of a VM thread blocked in write. But to >>>>> reproduce it, you would need a device that can be made to stop >>>>> responding... >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> >>>>> On 30.09.2006, at 14:41, 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ > >>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at 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 Tue Oct 3 08:42:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 03 Oct 2006 09:42:09 -0500 Subject: [Rxtx] Definition for close() In-Reply-To: <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> <08956081-C637-4CE9-AC31-CB74BA090081@buechse.de> <2F1310B5-D9BE-4A41-A487-F281682D13E2@buechse.de> Message-ID: <452276C1.3070907@cox.net> Joachim Buechse wrote: > I'd prefer a more p From tjarvi at qbang.org Sun Oct 15 15:02:24 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 15:02:24 -0600 (MDT) Subject: [Rxtx] testing Message-ID: We filled virtual partition that the mail-list resides on. I'm must testing to see everything is OK now. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 17:43:59 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 19:43:59 -0400 Subject: [Rxtx] mac learning experience Message-ID: <4532C7BF.1050506@suespammers.org> [two email messages I sent earlier apparently were lost in the disk full issue; this is a summary and conclusion as I now think I know what was going on.] I went back to work on my project yesterday after taking a few weeks off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter on my Powerbook; I was getting the traditional PortInUse message but the lock directory was there, correctly owned, and the lock files were being managed properly, and I was getting pretty frustrated. Then, the Mac did something I've never seen before -- the kernel locked up and I got a mandatory restart message. On boot, it complained about a problem in the keyspan drivers. A quick retry of my software, and RXTX worked correctly and hooked to the port. I investigated the Keyspan web site and saw that there have been two releases of newer drivers, so I've updated and hopefully won't see the problem again. So anyway, it appears that on OX X, PortInUseException can be generated intermittently by out-of-date Keyspan USB drivers. richard From tjarvi at qbang.org Sun Oct 15 18:04:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 15 Oct 2006 18:04:40 -0600 (MDT) Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: On Sun, 15 Oct 2006, Richard P. Welty wrote: > [two email messages I sent earlier apparently were lost in the > disk full issue; this is a summary and conclusion as I now think > I know what was going on.] > > I went back to work on my project yesterday after taking a few weeks > off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter > on my Powerbook; I was getting the traditional PortInUse message but > the lock directory was there, correctly owned, and the lock files were > being managed properly, and I was getting pretty frustrated. > > Then, the Mac did something I've never seen before -- the kernel locked > up and I got a mandatory restart message. On boot, it complained about > a problem in the keyspan drivers. A quick retry of my software, and > RXTX worked correctly and hooked to the port. > > I investigated the Keyspan web site and saw that there have been two > releases of newer drivers, so I've updated and hopefully won't see the > problem again. > > So anyway, it appears that on OX X, PortInUseException can be generated > intermittently by out-of-date Keyspan USB drivers. > Thanks Richard Sorry for the cryptic message about the disk being full. Sometimes the people behind the curtains get swamped and by the time they crawl out of a hole, a quick post is about all they are capable of :) The USB dongles in general have not as much time to work out their drivers as traditional onboard serial ports. These dongles even have a UART in them so they offer a great way for people to keep using 'simple' serial support on laptops and computers without serial ports. But as you mentioned, there can be problems. This is not unique to Mac OS X or to USB Serial Dongles. Sometimes we see problems with Multiport serial cards too. Both in rxtx and in the vendors drivers. With multiport cards, we just have not tested very much. With USB Dongles, they are new and still working out the bugs. Sharing these observations gives others a chance to figure out whats wrong. If we know a specific vendor has issues, we can also bring it to their attention. -- Trent Jarvi tjarvi at qbang.org From rwelty at suespammers.org Sun Oct 15 18:58:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 20:58:06 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: References: <4532C7BF.1050506@suespammers.org> Message-ID: <4532D91E.3060608@suespammers.org> Trent Jarvi wrote: > Sharing these observations gives others a chance to figure out whats > wrong. If we know a specific vendor has issues, we can also bring it to > their attention. In this particular case, I suspect that an automagic upgrade to OS X probably broke the Keyspan driver, hence the updates on the Keyspan site. It didn't occur to me to check when I upgraded the Mac, but now I know that I need to. richard From rwelty at suespammers.org Sun Oct 15 19:01:10 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sun, 15 Oct 2006 21:01:10 -0400 Subject: [Rxtx] bluetooth serial Message-ID: <4532D9D6.5060704@suespammers.org> I'm looking at some of the bluetooth-serial adapters out there as a way to reduce cable clutter; the idea is to attach the adapter to the serial device and use bluetooth in my powerbook to talk to the adapter. Does anyone have any experience using this type of hardware setup with RXTX? thanks, richard From naranjo.manuel at gmail.com Sun Oct 15 19:11:36 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 15 Oct 2006 22:11:36 -0300 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <4532DC48.7080005@gmail.com> Richard, Yes I have used the AIRcable devices with a lot of success. There is even a Linux driver made by me. This devices emulates a Serial Cable over the AIR. If you need more info about the products, please contact me to my personal email. Cheers, Manuel > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From ralf at lehmann.cc Mon Oct 16 00:00:50 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Mon, 16 Oct 2006 08:00:50 +0200 Subject: [Rxtx] Install failure after compile Message-ID: <45332012.6010908@lehmann.cc> Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 332 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/c23db30f/ralf-0008.vcf From colin.chaballier at orange-ft.com Mon Oct 16 01:09:32 2006 From: colin.chaballier at orange-ft.com (zze-CHABALLIER Colin RD-BIZZ-SOP) Date: Mon, 16 Oct 2006 09:09:32 +0200 Subject: [Rxtx] Exceptions in writeArray Message-ID: Hi everyone, I'm developing a Java application to interface an ARM/linux box to an external card through RS232. I'm getting difficulties with RXTX, particularly with exceptions caught when I call the write method on my Outputstream. These IOExceptions ("java.io.Exception : Input/output exception in writeArray") occur in specific conditions. They occur each time I call write(), but only around 10 seconds after the first call to write, and it doesn't matters how many calls to write() I do in these 10 seconds. For example : t=0, I open the port t=5, call to write() ->OK t=8, call to write -> OK t=11, call to write -> OK t=16, call to write -> Exception ... and all following calls lead to exceptions. I suppose that there is a tricky thing to do when configuring the port or before/after calling write(). The problem seems to come from an internal timeout or something like that. Thank you for your expertise. Regards, Colin HW : Compulab CM-X255 (ARM/xscale) OS : Debian kernel 2.6 JVM : JamVM 1.4.1 RXTX : RXTX-2.1-7pre20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/f6ae28a5/attachment-0008.html From tod at todbot.com Mon Oct 16 02:25:22 2006 From: tod at todbot.com (Tod E. Kurt) Date: Mon, 16 Oct 2006 01:25:22 -0700 Subject: [Rxtx] bluetooth serial In-Reply-To: <4532D9D6.5060704@suespammers.org> References: <4532D9D6.5060704@suespammers.org> Message-ID: <8D80DDCC-BDBF-475F-8D10-96AA00994770@todbot.com> Hi, I've used several different Bluetooth serial adapters on my Powerbook with RXTX. Once you've paired the device with your laptop, it appears as just another serial port. The steps I used to pair and configure one of these adapters are described here: http://todbot.com/blog/2006/02/23/howto-mac-os-x-bluetooth-serial-port/ In my experience, the Bluetooth serial adapters work great and it's hard to tell when you're using them, except for: a) the first time connecting may take several seconds more than normal as it establishes the radio link, and b) I'm pretty sure hardware handshaking functions like setDTR() will not work. -=tod On Oct 15, 2006, at 6:01 PM, Richard P. Welty wrote: > I'm looking at some of the bluetooth-serial adapters out > there as a way to reduce cable clutter; the idea is to > attach the adapter to the serial device and use bluetooth > in my powerbook to talk to the adapter. Does anyone have > any experience using this type of hardware setup with > RXTX? > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From arun at akorp.com Mon Oct 16 02:30:01 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Mon, 16 Oct 2006 08:30:01 +0000 Subject: [Rxtx] Install failure after compile Message-ID: <20061016083002.17461.qmail@server212.com> Hi Ralf, I faced this problem just recently, though on Windows XP. The mailman archives of the mailing list appears to be down, but at any rate here is the URL of a posting related to this problem: [LINK: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html Briefly this is what needs to be done: 1. According to a reply I got from Andy, check to see if gnu.io.rxtx.properties is being used or picked up somewhere. It wasn't the case on my Windows system, but I'm not sure if it would be different on Linux. If this is the case then comment out line 362 in the RXTXCommDriver.java file. The line is: System.setProperties(p); 2. The NullPointerException occurs because the initialize method of RXTXCommDriver is not being called. One work around is change Test.java and below line 27 make this change 27 RXTXCommDriver TxPort = new RXTXCommDriver(); >>>(insert) TxPort.initialize(); 28 System.out.println(".."); 29 serialPort = (SerialPort) TxPort.getCommPort(PortName, CommPortIdentifier.PORT_SERIAL); Basically manually call initialize before making the call to getCommPort. This is one solution, but what I gather from Trent is this is not the preferred way of getting a handle to ports. Therefore Test.java itself is probably a bit old and needs to be removed or updated. Here is some code that Trent sent me to demonstrate how to get a handle on a port: public static void main(String[] args) { if (args.length < 1) { System.out.print("SimpleRead.class /dev/ttyxx\n"); System.exit(-1); } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(args[0])) { SimpleRead reader = new SimpleRead(); } } } } public SimpleRead() { try { serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); ... So in summary, if you want to use Test.java, call initialize before getCommPort. Or drop the Test.java approach all together and use CommPortIdentifier to get access to the comm port. Hope this helps. Cheers, Arun -------Original Message------- From: Ralf Lehmann Subject: [Rxtx] Install failure after compile Sent: 16 Oct '06 06:00 Hi, i compiled the rxtx-2.1-7r2 package without any problems but after doing a "make install" i get this error: make install make all-am make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. System :Opensuse 10.2/Kernel 2.6.18/gcc-Version 4.1.2 20060913 The binary's not usually for me because there is somthing wrong in the RXTXCommDriver.java:800 if(osName.toLowerCase().indexOf("windows") == -1 ) // i get there a null pointer Exception. So i put a 1==2 in the if to get it always false. :-) and get this error when running Test.java: ralf at sandra:~/rxtx-2.1-7r2/contrib> sudo java Test /dev/ttyS0 opening the Port: /dev/ttyS0 Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 open Ports RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0 Get Streams java.lang.NullPointerException at Test.(Test.java:32) at Test.main(Test.java:23) java.lang.NullPointerException at Test.(Test.java:38) at Test.main(Test.java:23) Exception in thread "main" java.lang.NullPointerException at Test.(Test.java:43) at Test.main(Test.java:23) Please give me a hint to get clear the make install feature so i could start hacking thanks Ralf -------------------- _______________________________________________ Rxtx mailing list [LINK: http://mbox.akorp.com/compose.php?to=Rxtx at qbang.org] Rxtx at qbang.org [LINK: http://mailman.qbang.org/mailman/listinfo/rxtx] http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/00764881/attachment-0008.html From lyon at docjava.com Mon Oct 16 03:09:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 16 Oct 2006 05:09:49 -0400 Subject: [Rxtx] mac learning experience In-Reply-To: <4532C7BF.1050506@suespammers.org> References: <4532C7BF.1050506@suespammers.org> Message-ID: Thank Richard, I have switched from the PortIO to Keyspan device. A new Keyspan driver sound encouraging. Things are looking pretty good, so far. I suspect that the PortIO driver is the source of the PortInUseException, just like the older Keyspan driver. Regards, - DL >[two email messages I sent earlier apparently were lost in the >disk full issue; this is a summary and conclusion as I now think >I know what was going on.] > >I went back to work on my project yesterday after taking a few weeks >off. I couldn't get RXTX to connect to the Keyspan USB->Serial adapter >on my Powerbook; I was getting the traditional PortInUse message but >the lock directory was there, correctly owned, and the lock files were >being managed properly, and I was getting pretty frustrated. > >Then, the Mac did something I've never seen before -- the kernel locked >up and I got a mandatory restart message. On boot, it complained about >a problem in the keyspan drivers. A quick retry of my software, and >RXTX worked correctly and hooked to the port. > >I investigated the Keyspan web site and saw that there have been two >releases of newer drivers, so I've updated and hopefully won't see the >problem again. > >So anyway, it appears that on OX X, PortInUseException can be generated >intermittently by out-of-date Keyspan USB drivers. > >richard >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Mon Oct 16 16:42:38 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 16 Oct 2006 18:42:38 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <45340ADE.30604@suespammers.org> can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard From arun at akorp.com Mon Oct 16 18:19:23 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 00:19:23 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017001923.2447.qmail@server212.com> Hi, I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event is triggered, with no success. I am using the event to toggle the RTS line. I have the following code (truncated for brevity): private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; private SerialPort port; private InputStream inPort; private OutputStream outPort; {initialize port, get inPort and outPort} port.addEventListener(this); port.notifyOnDataAvailable(true); port.notifyOnOutputEmpty(true); port.setSerialPortParams(..); public void write(byte[] packet) { port.setRTS(true); outPort.write(packet); outPort.flush(); System.out.println("Sent packet"); } public void serialEvent(SerialPortEvent e) { switch (e.getEventType()) { case SerialPortEvent.OUTPUT_BUFFER_EMPTY: System.out.println("Buffer empty setting RTS low"); port.setRTS(false); //port.notifyOnDataAvailable(true); tried adding this to see if it made a difference its already called in constructor break; case SerialPortEvent.DATA_AVAILABLE: System.out.println("Data available"); if (inPort.available() > 0) { {read inPort and dump to System.out} } break; } } The output I get is: Buffer empty setting RTS low Buffer empty setting RTS low Sent packet Why does the event get called twice on a single write? I am writing a packet with 8 bytes. Is this the right way to do what I want (toggle RTS between write and read)? Thanks, Arun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061016/7f775c5c/attachment-0008.html From tjarvi at qbang.org Mon Oct 16 18:55:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 18:55:57 -0600 (MDT) Subject: [Rxtx] Exceptions in writeArray In-Reply-To: References: Message-ID: On Mon, 16 Oct 2006, zze-CHABALLIER Colin RD-BIZZ-SOP wrote: > Hi everyone, > > I'm developing a Java application to interface an ARM/linux box to an > external card through RS232. > > I'm getting difficulties with RXTX, particularly with exceptions caught > when I call the write method on my Outputstream. > These IOExceptions ("java.io.Exception : Input/output exception in > writeArray") occur in specific conditions. They occur each time I call > write(), but only around 10 seconds after the first call to write, and > it doesn't matters how many calls to write() I do in these 10 seconds. > For example : > t=0, I open the port > t=5, call to write() ->OK > t=8, call to write -> OK > t=11, call to write -> OK > t=16, call to write -> Exception > ... and all following calls lead to exceptions. > > I suppose that there is a tricky thing to do when configuring the port > or before/after calling write(). The problem seems to come from an > internal timeout or something like that. > Thank you for your expertise. > > Regards, Colin > > > > HW : Compulab CM-X255 (ARM/xscale) > OS : Debian kernel 2.6 > JVM : JamVM 1.4.1 > RXTX : RXTX-2.1-7pre20 > > > Hi Colin Thats the C level write(2) failing for some reason. write is returning a negative number. This suggests something is going on in the driver or perhaps your hardware. At least I think thats EIO you are getting. You can look at the writeArray function in SerialImp.c -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:17:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:17:49 -0600 (MDT) Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: On Mon, 16 Oct 2006, Arun Kumar wrote: > Hi Ralf, > I faced this problem just recently, though on Windows XP. The mailman > archives of the mailing list appears to be down, but at any rate here is > the URL of a posting related to this problem: [LINK: > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html] > http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060227/391158.html > > Hi Arun Thanks for pointing out the problem. It's fixed now. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Oct 16 19:27:40 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Oct 2006 19:27:40 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017001923.2447.qmail@server212.com> References: <20061017001923.2447.qmail@server212.com> Message-ID: On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi tjarvi at qbang.org From tpw3316 at ACRretail.com Tue Oct 17 04:40:45 2006 From: tpw3316 at ACRretail.com (Tim Wilkinson) Date: Tue, 17 Oct 2006 06:40:45 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line Message-ID: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Hi Richard, I've worked with several Epson TM- type printers with both serial and USB connections. In my experience, if you are on a Linux platform, the device file created by Linux (/dev/USB...) is usable as either a file or a serial port. For RXTX to recognize it as a port, the device file name in /dev needs to match the /dev/ttyS?? pattern. I've done this with a symbolic link pointing back to the USB device file created by Linux. The problem of the USB file coming and going dynamically and possibly changing device file names is an issue though. We have switched to using javax.usb on Linux for Epson's USB line with great success. That allows for dynamic detection and attachment. Also, Epson's USB implementation is straight forward. Once open, it is just simple reads and writes to interact with the printer using the same protocol that would be used via a serial connection. Hope that helps, Tim -----Original Message----- From: Richard P. Welty [mailto:rwelty at suespammers.org] Sent: Monday, October 16, 2006 6:43 PM To: RXTX Developers and Users Subject: [Rxtx] RXTX & Epson TM-T88 printer line can anyone tell me anything about working with these? i've used them on parallel ports in the past, in raw mode just pushing bytes out, and rather like them, but i have a USB TM-T88IV on my desk right now and i'm having a really difficult time prying drivers for it out of Epson, and while it's showing up on the USB list in system preferences, it's not showing up as a serial port where RXTX can see it. thanks in advance, richard _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Tue Oct 17 05:09:51 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Oct 2006 07:09:51 -0400 Subject: [Rxtx] dymo In-Reply-To: <45340ADE.30604@suespammers.org> References: <45340ADE.30604@suespammers.org> Message-ID: Hi All, Has anyone had any luck using RXTX to drive the Dymo Laberwriter? Thanks! - DL From rwelty at suespammers.org Tue Oct 17 05:22:06 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Tue, 17 Oct 2006 07:22:06 -0400 Subject: [Rxtx] RXTX & Epson TM-T88 printer line In-Reply-To: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> References: <89BABD89E119D311BEFD00062905BAE417072B21@jaxmail.acr2000.com> Message-ID: <4534BCDE.2030206@suespammers.org> Tim Wilkinson wrote: > Hi Richard, > > I've worked with several Epson TM- type printers with both serial and USB > connections. In my experience, if you are on a Linux platform, the device > file created by Linux (/dev/USB...) is usable as either a file or a serial > port. For RXTX to recognize it as a port, the device file name in /dev > needs to match the /dev/ttyS?? pattern. I've done this with a symbolic > link pointing back to the USB device file created by Linux. The problem of > the USB file coming and going dynamically and possibly changing device file > names is an issue though. We have switched to using javax.usb on Linux for > Epson's USB line with great success. That allows for dynamic detection and > attachment. Also, Epson's USB implementation is straight forward. Once > open, it is just simple reads and writes to interact with the printer using > the same protocol that would be used via a serial connection. Thanks. I forgot to mention that right now I'm working on OS X, and there are no drivers to set up the serial link in /dev. I have noticed that the Mac setup works a little differently; the serial lines all seem to be identifiable by their special device numbering, not by name. But no link is being set up when the device is plugged in. I'm looking at javax.usb but I'll have to write the shim between the common code and the Mac USB subsystem, nobody seems to have done that. richard From arun at akorp.com Tue Oct 17 08:25:36 2006 From: arun at akorp.com (=?iso-8859-1?Q?Arun=20Kumar?=) Date: Tue, 17 Oct 2006 14:25:36 +0000 Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Message-ID: <20061017142536.28757.qmail@server212.com> Hi Trent, You are right, I am using it to communicate with RS485. I have looked up the message archives and found some posts regarding RS485 which basically suggested a hardware solution for this. I have discussed this with my hardware designer and we are trying to explore all options. Earlier I did toggle the RTS line after the flush, which didn't work. I then tried inserting a Thread.sleep(), which worked intermittently. The ideal situation would be to have the RTS toggled as soon as the last bit is sent. Just so I understand it, the reason the software toggle isn't ideal is because the system works differently on different OSes, and in some cases it might be hard to determine when the output buffer is empty? Is that right? Are the any other issues besides that? You mentioned timing, and I think I saw something you had written in a post regarding OS kernel issues. Could you elaborate on that, or point me to where I can get more information? Meanwhile I'll dig into the code and see if I can figure out for myself what exactly is going on. Thanks, Arun -------Original Message------- From: Trent Jarvi Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY Sent: 17 Oct '06 01:27 On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi, > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY event > is triggered, with no success. I am using the event to toggle the RTS line. > > I have the following code (truncated for brevity): > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes }; > private SerialPort port; > private InputStream inPort; > private OutputStream outPort; > > > > > {initialize port, get inPort and outPort} > port.addEventListener(this); > port.notifyOnDataAvailable(true); > port.notifyOnOutputEmpty(true); > port.setSerialPortParams(..); > > > public void write(byte[] packet) { > port.setRTS(true); > outPort.write(packet); > outPort.flush(); > System.out.println("Sent packet"); > } > > public void serialEvent(SerialPortEvent e) { > switch (e.getEventType()) { > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > System.out.println("Buffer empty setting RTS low"); > port.setRTS(false); > //port.notifyOnDataAvailable(true); tried adding this to see > if it made a difference its already called in constructor > break; > case SerialPortEvent.DATA_AVAILABLE: > System.out.println("Data available"); > if (inPort.available() > 0) { > {read inPort and dump to System.out} > } > break; > } > } > > The output I get is: > Buffer empty setting RTS low > Buffer empty setting RTS low > Sent packet > > Why does the event get called twice on a single write? I am writing a > packet with 8 bytes. Is this the right way to do what I want (toggle RTS > between write and read)? > > Thanks, > > Arun > Hi Arun Depending upon the OS and whats going on, output buffer may not be the solution you expect. Some ports and even some OS's do not let us see what is on the UART. There is an actual bit flipped that we can indirectly see on most OSes. So we can follow with basically a flush() call. Flush returns when the data is written. So you can do one of two things... see if the data is flushed with your own flush call then flip the RTS or look through the native code and make sure there isnt a code path that can produce two output empty events. Be warned... Most people flipping RTS after write are trying to do something like RS485 which has timing implications. There are inexpensive hardware solutions that can do a better job in such cases. The multiple output buffer observation may be a problem I'm observing too. Its just a little complicated to work out for all OS's and hardware. I suspect the error is trivial when identified though. -- Trent Jarvi [LINK: http://mbox.akorp.com/compose.php?to=tjarvi at qbang.org] tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/ff45ecc2/attachment-0008.html From ralf at lehmann.cc Tue Oct 17 16:34:40 2006 From: ralf at lehmann.cc (Ralf Lehmann) Date: Wed, 18 Oct 2006 00:34:40 +0200 Subject: [Rxtx] Install failure after compile In-Reply-To: <20061016083002.17461.qmail@server212.com> References: <20061016083002.17461.qmail@server212.com> Message-ID: <45355A80.4020406@lehmann.cc> Thanks Arun, so i could build a working jar. The "make install" failure of the rxtx-2.1-7r2-package i have solved. > make install > make all-am > make[1]: Entering directory `/home/ralf/rxtx-2.1-7r2' > make[1]: Leaving directory `/home/ralf/rxtx-2.1-7r2' > libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory > Try `libtool --help --mode=install' for more information. > in the makefile RXTX_PATH and JHOME are undefined. If i point them to a directory the install works. I don't no why they are undefined the other java-specific variables are correctly defined. thanks ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: ralf.vcf Type: text/x-vcard Size: 318 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20061017/37b6aa66/ralf-0008.vcf From tjarvi at qbang.org Tue Oct 17 21:18:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 17 Oct 2006 21:18:17 -0600 (MDT) Subject: [Rxtx] Info on OUTPUT_BUFFER_EMPTY In-Reply-To: <20061017142536.28757.qmail@server212.com> References: <20061017142536.28757.qmail@server212.com> Message-ID: Hi Arun The main problem you face while trying to do RS485 is timing. Kernels do not typically offer the reponse times you require "by contract." You can do it, it will sometimes work. If you tinker with your own kernel, it can always work. You probably want it to work all the time and on many kernels. That's a nightmare to support. You are probably going to be using kernels that take interrupts as suggestions to interrupt operation :) So you have an OS scheduler to deal with. There will be a Java scheduler also. By trying to support RS485 in java, you are signing up to be the contract that covers all of that within the time limits of your protocol. I know people have hacked kernel serial drivers to get RS485 working in the past. It is possible. Even more so with realtime Linux going mainstream soon if not already. The original changes did not make it into mainstream Linux kernels because [my opinion] the kernel developers did not want to be limited by such timing constraints. It is not possible for the rxtx project to support such activies simply because of the complexity of the pieces involved. "Whenever I start a web browser, my RS485 connection gets all messed up" Thats just not a 'bug' people want to chase in their free time. Especially if a hardware solution can be as little as $5 US with some creativity. On Tue, 17 Oct 2006, Arun Kumar wrote: > Hi Trent, > You are right, I am using it to communicate with RS485. I have looked up > the message archives and found some posts regarding RS485 which basically > suggested a hardware solution for this. I have discussed this with my > hardware designer and we are trying to explore all options. > > Earlier I did toggle the RTS line after the flush, which didn't work. I > then tried inserting a Thread.sleep(), which worked intermittently. The > ideal situation would be to have the RTS toggled as soon as the last bit > is sent. > > Just so I understand it, the reason the software toggle isn't ideal is > because the system works differently on different OSes, and in some cases > it might be hard to determine when the output buffer is empty? Is that > right? Are the any other issues besides that? You mentioned timing, and I > think I saw something you had written in a post regarding OS kernel > issues. Could you elaborate on that, or point me to where I can get more > information? > > Meanwhile I'll dig into the code and see if I can figure out for myself > what exactly is going on. > > Thanks, > > Arun > > > -------Original Message------- > From: Trent Jarvi > Subject: Re: [Rxtx] Info on OUTPUT_BUFFER_EMPTY > Sent: 17 Oct '06 01:27 > > On Tue, 17 Oct 2006, Arun Kumar wrote: > > > Hi, > > I have been trying to figure out how exactly the OUTPUT_BUFFER_EMPTY > event > > is triggered, with no success. I am using the event to toggle the RTS > line. > > > > I have the following code (truncated for brevity): > > > > > > private byte[] samplePacket = { (byte) 0xFF, (byte) 0xAA, 6 more bytes > }; > > private SerialPort port; > > private InputStream inPort; > > private OutputStream outPort; > > > > > > > > > > {initialize port, get inPort and outPort} > > port.addEventListener(this); > > port.notifyOnDataAvailable(true); > > port.notifyOnOutputEmpty(true); > > port.setSerialPortParams(..); > > > > > > public void write(byte[] packet) { > > port.setRTS(true); > > outPort.write(packet); > > outPort.flush(); > > System.out.println("Sent packet"); > > } > > > > public void serialEvent(SerialPortEvent e) { > > switch (e.getEventType()) { > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > System.out.println("Buffer empty setting RTS low"); > > port.setRTS(false); > > //port.notifyOnDataAvailable(true); tried adding this to see > > if it made a difference its already called in constructor > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > System.out.println("Data available"); > > if (inPort.available() > 0) { > > {read inPort and dump to System.out} > > } > > break; > > } > > } > > > > The output I get is: > > Buffer empty setting RTS low > > Buffer empty setting RTS low > > Sent packet > > > > Why does the event get called twice on a single write? I am writing a > > packet with 8 bytes. Is this the right way to do what I want (toggle > RTS > > between write and read)? > > > > Thanks, > > > > Arun > > > > Hi Arun > > Depending upon the OS and whats going on, output buffer may not be the > solution you expect. Some ports and even some OS's do not let us see > what > is on the UART. There i