From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0001.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0002.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0001.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0004.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0002.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0002.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0005.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0003.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0003.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0001.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0006.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0004.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0004.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0002.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0001.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0007.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0005.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0005.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0004.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0002.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment-0001.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From ajmas at sympatico.ca Sat Dec 8 08:13:26 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 8 Dec 2007 10:13:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> On 7-Dec-07, at 14:26 , Beat Arnet wrote: > > On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. > > > Well, that's certainly what you get when electrical engineers like > me write software ;) > > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > > > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. If you can you should assign the responsibility of closing the port to the one handling the port. The other thread should simply be telling the handling thread that it should close the port. Threads are like people, in that if you give them conflicting instructions all hell breaks loose. For example of what I think you should do: class MyClass { private boolean continueReading = true; public void run() { InputStream in = null; try { in = createMyInputStream(); // or however int len = 0; byte[] buffer = new byte[1024]; while ( (len = in.read(buffer)) > 0 && continueReading ) { // handle the read data } } catch ( IOException ex ) { } finally { if ( in != null ) { in.close(); } } } } Andre From netbeans at gatworks.com Sat Dec 8 16:25:43 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 08 Dec 2007 18:25:43 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: <475B27F7.5040500@gatworks.com> >> But I am not talking about multiple threads reading from the same >> port. I am dealing with a case in which one thread is reading from the >> port, and another wants to close the port. > So I looked at the RXTX code ( close(), read() ) ( is that what u were trying to point out ? ) and it seems that a close() may not close. If there is heavy reading, then maybe close wont happen at all. Not sure why read is synchronized. If someone wants to read - uncoordinated, then that his option! But the read() and the close() does not appear to have a strong method of synchronization ( close should set a flag, that would cause any further I/O requests to throw an exception ). On would think that a close() would also prevent any further write() operations. But it does not. It also does not appear to wait for the write( b[] ) to complete ( in case the array has to be written out in chunks bec the kernel buffer is full. ) Does this help any? :-} From vorobyev.a at gmail.com Sun Dec 9 01:31:05 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Sun, 09 Dec 2007 11:31:05 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475BA7C9.6090900@gmail.com> Good day. Following problem: Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Java 6 - 1.6.02 OS OpenSuse 10.3, 2.6.22.13-0.3-default I have attach USB printer: Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device found, idVendor=088c, idProduct=2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Product: TTP 2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Manufacturer: Swecoin AB Dec 8 09:25:46 linux-fceg kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x088C pid 0x2030 Dec 8 09:25:46 linux-fceg kernel: usbcore: registered new interface driver usblp Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver linux-fceg:/var/log # ll /dev/usb* lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 Example: Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { CommPortIdentifier portIdentifier = (CommPortIdentifier) portEnum.nextElement(); System.out.println(portIdentifier.getName() + " - " + getPortTypeName(portIdentifier.getPortType())); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial Virtual LPT port not found... Parallel port /dev/lp0 not foud also. After that i modified source RXTXCommDriver.java, registerScannedPorts if (osName.equals("Linux") { String[] temp = { "lp", // linux printer port "usblp" <====================== add this }; CandidatePortPrefixes = temp; } else if (osName.equals("FreeBSD")) { But /dev/usblp0 not found anyway. After that i modified registerValidPorts if (osName.equals("Solaris") || osName.equals("SunOS")) { checkSolaris(PortName, PortType); } else { if (PortType==CommPortIdentifier.PORT_PARALLEL) <<<< i.e. port type is parallel - don't execute testRead CommPortIdentifier.addPortName( PortName,PortType,this); <<<< else if (testRead(PortName, PortType)) CommPortIdentifier.addPortName( PortName,PortType,this); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial /dev/usblp0 - Parallel /dev/lp0 - Parallel I think, what native testRead incorrectly defines presence of parallel port. I think that presence parallel port can be checked up so: int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) // port is not exist or it is not parallel port else // port is parallel! After that i execute program: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 5000); String str = "12313212312313121231321231231312"; port.getOutputStream().write(str.getBytes()); port.close(); Result: RXTXCommDriver:getCommPort(/dev/usblp0,2) LPRPort:LPRPort(/dev/usblp0) Port /dev/usblp0 in use by another application gnu.io.PortInUseException: Unknown Linux Application linux-fceg:/var/log # lsof | grep /dev/usb I.e. port is not use. Similar result at use /dev/lp0 How i can use parallel ports in my program? PS: Sorry for my english :) From tjarvi at qbang.org Sun Dec 9 00:03:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 00:03:51 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: On Sat, 8 Dec 2007, U. George wrote: >>> But I am not talking about multiple threads reading from the same >>> port. I am dealing with a case in which one thread is reading from the >>> port, and another wants to close the port. >> > So I looked at the RXTX code ( close(), read() ) ( is that what u were > trying to point out ? ) and it seems that a close() may not close. If > there is heavy reading, then maybe close wont happen at all. > > Not sure why read is synchronized. If someone wants to read - > uncoordinated, then that his option! > But the read() and the close() does not appear to have a strong method > of synchronization ( close should set a flag, that would cause any > further I/O requests to throw an exception ). > > On would think that a close() would also prevent any further write() > operations. But it does not. It also does not appear to wait for the > write( b[] ) to complete ( in case the array has to be written out in > chunks bec the kernel buffer is full. ) > Hi George, The code may not look conventional because I wasnt looking at other code at the time. It does do close to what you expect. The code got there the hard way though. close sets the fd to 0 which should throw exceptions if you try IO. while( IOLocked > 0 ) should delay close while reading and writing are in progress. In write(b[]) the following code can be found (comments added): // throw exception if closed. if ( fd == 0 ) throw new IOException(); // prevent closing while writing. IOLocked++; // Ensure the event thread is not being setup. ie // open() waitForTheNativeCodeSilly(); read() has the same logic (deleting some code for clairity) if ( fd == 0 ) throw new IOException(); IOLocked++; waitForTheNativeCodeSilly(); The close(): (for clairity just the code that we care about here:) while( IOLocked > 0 ) { sleep() } removeEventListener(); nativeClose( this.name ); fd = 0; -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 03:35:47 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 05:35:47 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475BA7C9.6090900@gmail.com> References: <475BA7C9.6090900@gmail.com> Message-ID: <475BC503.7010708@gatworks.com> > > linux-fceg:/var/log # ll /dev/usb* > lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 I suppose this is your first issue i would have expected a /dev/usblp0 ->/dev/lp1 ( since most machines have a /dev/lp0 ) > > result: > /dev/ttyS2 - Serial > /dev/ttyS1 - Serial > /dev/ttyS0 - Serial > Virtual LPT port not found... Parallel port /dev/lp0 not foud also. thats bec lp0 its in /dev/usb ! > > LPRPort:LPRPort(/dev/usblp0) > Port /dev/usblp0 in use by another application > gnu.io.PortInUseException: Unknown Linux Application rxtx code: int fd = open( filename, O_RDWR | O_NONBLOCK ); rxtx appears to want to be able to open the device for reading AND writing. I suspect permission failure. 1) anyway have a symbolic pointer from /dev/usb/usblp0 to /dev/lp0 2) change permissions to be RW for you group or owner. From netbeans at gatworks.com Sun Dec 9 04:44:35 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 06:44:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <475BD523.3000900@gatworks.com> > close sets the fd to 0 which should throw exceptions if you try IO. Setting fd to 0 appears to be the last step in rxtx-close. It should be the first step, as a mutex to prevent any further I/O to the channel. With hyperthreads, quad cpu's, other threads can be simultaneously ( in real time ) executing reads & writes & other things. > > while( IOLocked > 0 ) should delay close while reading and writing are > in progress. Yes, but there is nothing there to prevent any further user I/O. You could have a bunch of threads continue to read & write, and keep IOLock > 0 for some time. Even if it did reach IOLock reached 0, there is still the possibility of some thread upping IOLock inbetween. > > In write(b[]) the following code can be found (comments added): > > // throw exception if closed. > if ( fd == 0 ) throw new IOException(); > // prevent closing while writing. Where is the "prevent further writing while closing" ? > > (for clairity just the code that we care about here:) > > while( IOLocked > 0 ) > { sleep() } this can take a long time to process. And defeats the purpose of a close() at time x. Because at time x+1, any further user requests to that file descriptor should have failed. One also has to ask why is the user program still reading or writing after having the close() called? But that is for the user to figure out. The orig question posed was to have a multi cpu, and 2 java threads. 1 thread was reading, while the other was ( attempting to ) closeing. probably something like this should be done: public close() { synchonize( eis ) { we_are_closing_up = true; while ( IOLock > 0 ) sleep( 100ms ); } native_close(); fd = 0; } we_are_closing_up = false; } public write() { if ( we_are_closing_up ) synchronize( eis ) { ; } if ( fd == 0 ) throw ( ..... IOLock++; ...... this is also not perfect. There is the possibility that a close could happen after the test, and before the IOLock++ From beat.arnet at gmail.com Sun Dec 9 05:44:23 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 09 Dec 2007 07:44:23 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475BE327.9010709@gmail.com> Thanks to all for responding to my original question! From what I hear, we now suspect that some improvements in RXTX might be necessary to make the code 100% thread safe. I would be happy to help, but I fear that I might not quite have the necessary training/skills. Maybe with some guidance I could give it a try. Since there has been no official release since 2.1.7, I am also wondering where I should start in the trunk so that I can be sure that all valid bug fixes that have been submitted sine 2.1.7 are included. However, I would also like to find out if there is something short-term that I can do in my application to avoid dead-locks on dual core machines, before RXTX is fixed. After Daniel's response, I synchronized all RXTXPort accesses, but I have still some crashes being reported from the field, albeit much less (and possibly unrelated?). Should I setup my code such that all accesses to the serial port happen in one unique thread? Would this prevent the problems that are described below? Any further guidance from the group would be appreciated. Regards, Beat U. George wrote: >> close sets the fd to 0 which should throw exceptions if you try IO. >> > Setting fd to 0 appears to be the last step in rxtx-close. It should be > the first step, as a mutex to prevent any further I/O to the channel. > With hyperthreads, quad cpu's, other threads can be simultaneously ( in > real time ) executing reads & writes & other things. > > > >> while( IOLocked > 0 ) should delay close while reading and writing are >> in progress. >> > Yes, but there is nothing there to prevent any further user I/O. You > could have a bunch of threads continue to read & write, and keep IOLock > > 0 for some time. > Even if it did reach IOLock reached 0, there is still the possibility of > some thread upping IOLock inbetween. > >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. >> > Where is the "prevent further writing while closing" ? > >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } >> > this can take a long time to process. And defeats the purpose of a > close() at time x. Because at time x+1, any further user requests to > that file descriptor should have failed. > One also has to ask why is the user program still reading or writing > after having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/6b16e64b/attachment.html From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0008.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0006.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0006.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0005.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0003.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment-0003.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From ajmas at sympatico.ca Sat Dec 8 08:13:26 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 8 Dec 2007 10:13:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> On 7-Dec-07, at 14:26 , Beat Arnet wrote: > > On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. > > > Well, that's certainly what you get when electrical engineers like > me write software ;) > > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > > > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. If you can you should assign the responsibility of closing the port to the one handling the port. The other thread should simply be telling the handling thread that it should close the port. Threads are like people, in that if you give them conflicting instructions all hell breaks loose. For example of what I think you should do: class MyClass { private boolean continueReading = true; public void run() { InputStream in = null; try { in = createMyInputStream(); // or however int len = 0; byte[] buffer = new byte[1024]; while ( (len = in.read(buffer)) > 0 && continueReading ) { // handle the read data } } catch ( IOException ex ) { } finally { if ( in != null ) { in.close(); } } } } Andre From netbeans at gatworks.com Sat Dec 8 16:25:43 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 08 Dec 2007 18:25:43 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: <475B27F7.5040500@gatworks.com> >> But I am not talking about multiple threads reading from the same >> port. I am dealing with a case in which one thread is reading from the >> port, and another wants to close the port. > So I looked at the RXTX code ( close(), read() ) ( is that what u were trying to point out ? ) and it seems that a close() may not close. If there is heavy reading, then maybe close wont happen at all. Not sure why read is synchronized. If someone wants to read - uncoordinated, then that his option! But the read() and the close() does not appear to have a strong method of synchronization ( close should set a flag, that would cause any further I/O requests to throw an exception ). On would think that a close() would also prevent any further write() operations. But it does not. It also does not appear to wait for the write( b[] ) to complete ( in case the array has to be written out in chunks bec the kernel buffer is full. ) Does this help any? :-} From vorobyev.a at gmail.com Sun Dec 9 01:31:05 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Sun, 09 Dec 2007 11:31:05 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475BA7C9.6090900@gmail.com> Good day. Following problem: Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Java 6 - 1.6.02 OS OpenSuse 10.3, 2.6.22.13-0.3-default I have attach USB printer: Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device found, idVendor=088c, idProduct=2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Product: TTP 2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Manufacturer: Swecoin AB Dec 8 09:25:46 linux-fceg kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x088C pid 0x2030 Dec 8 09:25:46 linux-fceg kernel: usbcore: registered new interface driver usblp Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver linux-fceg:/var/log # ll /dev/usb* lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 Example: Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { CommPortIdentifier portIdentifier = (CommPortIdentifier) portEnum.nextElement(); System.out.println(portIdentifier.getName() + " - " + getPortTypeName(portIdentifier.getPortType())); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial Virtual LPT port not found... Parallel port /dev/lp0 not foud also. After that i modified source RXTXCommDriver.java, registerScannedPorts if (osName.equals("Linux") { String[] temp = { "lp", // linux printer port "usblp" <====================== add this }; CandidatePortPrefixes = temp; } else if (osName.equals("FreeBSD")) { But /dev/usblp0 not found anyway. After that i modified registerValidPorts if (osName.equals("Solaris") || osName.equals("SunOS")) { checkSolaris(PortName, PortType); } else { if (PortType==CommPortIdentifier.PORT_PARALLEL) <<<< i.e. port type is parallel - don't execute testRead CommPortIdentifier.addPortName( PortName,PortType,this); <<<< else if (testRead(PortName, PortType)) CommPortIdentifier.addPortName( PortName,PortType,this); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial /dev/usblp0 - Parallel /dev/lp0 - Parallel I think, what native testRead incorrectly defines presence of parallel port. I think that presence parallel port can be checked up so: int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) // port is not exist or it is not parallel port else // port is parallel! After that i execute program: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 5000); String str = "12313212312313121231321231231312"; port.getOutputStream().write(str.getBytes()); port.close(); Result: RXTXCommDriver:getCommPort(/dev/usblp0,2) LPRPort:LPRPort(/dev/usblp0) Port /dev/usblp0 in use by another application gnu.io.PortInUseException: Unknown Linux Application linux-fceg:/var/log # lsof | grep /dev/usb I.e. port is not use. Similar result at use /dev/lp0 How i can use parallel ports in my program? PS: Sorry for my english :) From tjarvi at qbang.org Sun Dec 9 00:03:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 00:03:51 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: On Sat, 8 Dec 2007, U. George wrote: >>> But I am not talking about multiple threads reading from the same >>> port. I am dealing with a case in which one thread is reading from the >>> port, and another wants to close the port. >> > So I looked at the RXTX code ( close(), read() ) ( is that what u were > trying to point out ? ) and it seems that a close() may not close. If > there is heavy reading, then maybe close wont happen at all. > > Not sure why read is synchronized. If someone wants to read - > uncoordinated, then that his option! > But the read() and the close() does not appear to have a strong method > of synchronization ( close should set a flag, that would cause any > further I/O requests to throw an exception ). > > On would think that a close() would also prevent any further write() > operations. But it does not. It also does not appear to wait for the > write( b[] ) to complete ( in case the array has to be written out in > chunks bec the kernel buffer is full. ) > Hi George, The code may not look conventional because I wasnt looking at other code at the time. It does do close to what you expect. The code got there the hard way though. close sets the fd to 0 which should throw exceptions if you try IO. while( IOLocked > 0 ) should delay close while reading and writing are in progress. In write(b[]) the following code can be found (comments added): // throw exception if closed. if ( fd == 0 ) throw new IOException(); // prevent closing while writing. IOLocked++; // Ensure the event thread is not being setup. ie // open() waitForTheNativeCodeSilly(); read() has the same logic (deleting some code for clairity) if ( fd == 0 ) throw new IOException(); IOLocked++; waitForTheNativeCodeSilly(); The close(): (for clairity just the code that we care about here:) while( IOLocked > 0 ) { sleep() } removeEventListener(); nativeClose( this.name ); fd = 0; -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 03:35:47 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 05:35:47 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475BA7C9.6090900@gmail.com> References: <475BA7C9.6090900@gmail.com> Message-ID: <475BC503.7010708@gatworks.com> > > linux-fceg:/var/log # ll /dev/usb* > lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 I suppose this is your first issue i would have expected a /dev/usblp0 ->/dev/lp1 ( since most machines have a /dev/lp0 ) > > result: > /dev/ttyS2 - Serial > /dev/ttyS1 - Serial > /dev/ttyS0 - Serial > Virtual LPT port not found... Parallel port /dev/lp0 not foud also. thats bec lp0 its in /dev/usb ! > > LPRPort:LPRPort(/dev/usblp0) > Port /dev/usblp0 in use by another application > gnu.io.PortInUseException: Unknown Linux Application rxtx code: int fd = open( filename, O_RDWR | O_NONBLOCK ); rxtx appears to want to be able to open the device for reading AND writing. I suspect permission failure. 1) anyway have a symbolic pointer from /dev/usb/usblp0 to /dev/lp0 2) change permissions to be RW for you group or owner. From netbeans at gatworks.com Sun Dec 9 04:44:35 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 06:44:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <475BD523.3000900@gatworks.com> > close sets the fd to 0 which should throw exceptions if you try IO. Setting fd to 0 appears to be the last step in rxtx-close. It should be the first step, as a mutex to prevent any further I/O to the channel. With hyperthreads, quad cpu's, other threads can be simultaneously ( in real time ) executing reads & writes & other things. > > while( IOLocked > 0 ) should delay close while reading and writing are > in progress. Yes, but there is nothing there to prevent any further user I/O. You could have a bunch of threads continue to read & write, and keep IOLock > 0 for some time. Even if it did reach IOLock reached 0, there is still the possibility of some thread upping IOLock inbetween. > > In write(b[]) the following code can be found (comments added): > > // throw exception if closed. > if ( fd == 0 ) throw new IOException(); > // prevent closing while writing. Where is the "prevent further writing while closing" ? > > (for clairity just the code that we care about here:) > > while( IOLocked > 0 ) > { sleep() } this can take a long time to process. And defeats the purpose of a close() at time x. Because at time x+1, any further user requests to that file descriptor should have failed. One also has to ask why is the user program still reading or writing after having the close() called? But that is for the user to figure out. The orig question posed was to have a multi cpu, and 2 java threads. 1 thread was reading, while the other was ( attempting to ) closeing. probably something like this should be done: public close() { synchonize( eis ) { we_are_closing_up = true; while ( IOLock > 0 ) sleep( 100ms ); } native_close(); fd = 0; } we_are_closing_up = false; } public write() { if ( we_are_closing_up ) synchronize( eis ) { ; } if ( fd == 0 ) throw ( ..... IOLock++; ...... this is also not perfect. There is the possibility that a close could happen after the test, and before the IOLock++ From beat.arnet at gmail.com Sun Dec 9 05:44:23 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 09 Dec 2007 07:44:23 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475BE327.9010709@gmail.com> Thanks to all for responding to my original question! From what I hear, we now suspect that some improvements in RXTX might be necessary to make the code 100% thread safe. I would be happy to help, but I fear that I might not quite have the necessary training/skills. Maybe with some guidance I could give it a try. Since there has been no official release since 2.1.7, I am also wondering where I should start in the trunk so that I can be sure that all valid bug fixes that have been submitted sine 2.1.7 are included. However, I would also like to find out if there is something short-term that I can do in my application to avoid dead-locks on dual core machines, before RXTX is fixed. After Daniel's response, I synchronized all RXTXPort accesses, but I have still some crashes being reported from the field, albeit much less (and possibly unrelated?). Should I setup my code such that all accesses to the serial port happen in one unique thread? Would this prevent the problems that are described below? Any further guidance from the group would be appreciated. Regards, Beat U. George wrote: >> close sets the fd to 0 which should throw exceptions if you try IO. >> > Setting fd to 0 appears to be the last step in rxtx-close. It should be > the first step, as a mutex to prevent any further I/O to the channel. > With hyperthreads, quad cpu's, other threads can be simultaneously ( in > real time ) executing reads & writes & other things. > > > >> while( IOLocked > 0 ) should delay close while reading and writing are >> in progress. >> > Yes, but there is nothing there to prevent any further user I/O. You > could have a bunch of threads continue to read & write, and keep IOLock > > 0 for some time. > Even if it did reach IOLock reached 0, there is still the possibility of > some thread upping IOLock inbetween. > >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. >> > Where is the "prevent further writing while closing" ? > >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } >> > this can take a long time to process. And defeats the purpose of a > close() at time x. Because at time x+1, any further user requests to > that file descriptor should have failed. > One also has to ask why is the user program still reading or writing > after having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/6b16e64b/attachment-0001.html From tjarvi at qbang.org Sun Dec 9 11:01:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 11:01:00 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > >> close sets the fd to 0 which should throw exceptions if you try IO. > Setting fd to 0 appears to be the last step in rxtx-close. It should be the > first step, as a mutex to prevent any further I/O to the channel. With > hyperthreads, quad cpu's, other threads can be simultaneously ( in real time > ) executing reads & writes & other things. > > >> >> while( IOLocked > 0 ) should delay close while reading and writing are in >> progress. > Yes, but there is nothing there to prevent any further user I/O. You could > have a bunch of threads continue to read & write, and keep IOLock > 0 for > some time. > Even if it did reach IOLock reached 0, there is still the possibility of some > thread upping IOLock inbetween. >> >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. > Where is the "prevent further writing while closing" ? >> >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } > this can take a long time to process. And defeats the purpose of a close() at > time x. Because at time x+1, any further user requests to that file > descriptor should have failed. > One also has to ask why is the user program still reading or writing after > having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 thread > was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could happen > after the test, and before the IOLock++ > There are two questions in the back of my mind. The first is I'd like to see some form of documentation in the Java API that says this is the right behavior. Anything from file IO to network sockets. The second is that we are dealing with perhaps the slowest reads and writes out there. I'd anticipate some downstream impact (incompatability) with people using the current implementation. At least at first, a change like this should be something people opt into via preferences or other means. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 12:17:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 14:17:15 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C3F3B.9050003@gatworks.com> > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. ?? I'm not sure what behavior your are expecting the JAVA docs to explain? I'd be more interested in the OS docs that will/could explain the interaction of threads and the sequencing of I/O operations amongst active cpu instruction pipelines. > > The second is that we are dealing with perhaps the slowest reads and > writes out there. I'd anticipate some downstream impact > (incompatability) with people using the current implementation. At > least at first, a change like this should be something people opt into > via preferences or other means. u mean there are folks that continue to read & write even though they also issued a (premature) close ? I am not aware of any OS that behaves like that. Or allows that. Yes, but if you will notice, the the speed of USB devices, that are made to behave like serial, or parallel devices, are very-very fast. A 500ms sleep is forever on some USB devices. BTW: Since JAVA source went public, sorta, did java publish the commapi source? BTW#2:Your mail to 'Rxtx' with the subject If not DEBUGing, remove useless calls to report() et al Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 46243 bytes with a limit of 40 KB From netbeans at gatworks.com Sun Dec 9 13:00:09 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 15:00:09 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C4949.5060109@gatworks.com> > > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. from Class CommPort: After a communications port has been identified and opened it can be configured with the methods in the low-level classes like SerialPort and ParallelPort. Then an IO stream can be opend for reading and writing data. Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown. From dwippermann at gmx.net Sun Dec 9 13:36:28 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:36:28 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: Hi all, > If you can you should assign the responsibility of closing the port > to the one > handling the port. The other thread should simply be telling the > handling thread > that it should close the port. Threads are like people, in that if > you give them > conflicting instructions all hell breaks loose. For example of what > I think you > should do: > yes, that you be the common way if I had full control over the thread. But the thread is implemented and started by RXTX, I only get event through my listener. How should the listener be able to close the port if no event is triggered? Can I wake up the RXTX thread to send a dummy event to trigger the close from inside the listener? Daniel From dwippermann at gmx.net Sun Dec 9 13:55:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:55:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: And hi once more, > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ Thats the reason why I encapsulated all access in synchronized blocks using one mutex. You simply have no problem with "after ... , but before..." anymore :) One other problem I see is the use of the ++/-- operators on a variable that can be accessed by mutliple threads in parallel. I'll run a short test tomorrow on my office machine, but I assume that its read-modify-write behaviour might bring up a collision like: IOLocked = 100, both thread are running in different CPUs, but due to timing arrive at the "IOLocked--" nearly simultaneously CPU 1: reads variable to register => register = 100 CPU 2: doing something else -- CPU 1: decrements register => register = 99 CPU 2: reads variable to register => register = 100 -- CPU 1: writes register to variable => variable = 99 CPU 2: decrements register => register = 99 -- CPU 1: doing something else CPU 2: writes register to variable => variable = 99 It should have decremented twice, but it didn't... Thats a common situtation where locking is needed: modify the same variable from different threads without synchonization is hell :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/4bd9d474/attachment-0001.html From netbeans at gatworks.com Thu Dec 6 04:14:53 2007 From: netbeans at gatworks.com (U. George) Date: Thu, 06 Dec 2007 06:14:53 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al Message-ID: <4757D9AD.2080305@gatworks.com> For the most part the report() calls from everywhere is usefull in debugging whats happening within rxtx. BUT if you are not debugging, then it is just wasted CPU cycles. That also includes the sprintf's sprinkled here and there. I placed the DEBUG code ( SerialImp.c ) under the #ifdef DEBUG . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071206/92c448eb/attachment-0001.pl From tjarvi at qbang.org Sun Dec 9 19:15:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:15:44 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <4757D9AD.2080305@gatworks.com> References: <4757D9AD.2080305@gatworks.com> Message-ID: This looks OK to me George. Just two issues. make_message is probably copyrighted by the Free Software Foundation. It is probably easier to recode it than deal with the minor potential issues. The only other minor issue is that commenting out code isn't really better than deleting it in the long run. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 19:35:41 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 21:35:41 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> Message-ID: <475CA5FD.6050801@gatworks.com> Trent Jarvi wrote: > > This looks OK to me George. Just two issues. > > make_message is probably copyrighted by the Free Software Foundation. > It is probably easier to recode it than deal with the minor potential > issues. code u refer to is not used. I'm not too sure if "all" cc/libs can handle the particular var-args scheme. So if blows up, then that becomes an issue, but not harmfull for anybody's run. I did want to use it to do: REPORT("FIONREAD failed with error %s\n", strerror( errno )); or more recently REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); Since u PORT this to other machines, its not clear if var-args works everywhere the same way. u got any notion? > > The only other minor issue is that commenting out code isn't really > better than deleting it in the long run. > Sorta, sorta not. For short run ( in the heading of small changes ) it looks just like all the other items (historically) commented out, but not yet removed :) More things to clean up for the long run i guess. From tjarvi at qbang.org Sun Dec 9 19:47:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:47:37 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <475CA5FD.6050801@gatworks.com> References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> >> This looks OK to me George. Just two issues. >> >> make_message is probably copyrighted by the Free Software Foundation. It >> is probably easier to recode it than deal with the minor potential issues. > code u refer to is not used. I'm not too sure if "all" cc/libs can handle the > particular var-args scheme. So if blows up, then that becomes an issue, but > not harmfull for anybody's run. > > I did want to use it to do: > REPORT("FIONREAD failed with error %s\n", strerror( errno )); > > or more recently > > REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); > > Since u PORT this to other machines, its not clear if var-args works > everywhere the same way. u got any notion? > >> >> The only other minor issue is that commenting out code isn't really better >> than deleting it in the long run. >> > Sorta, sorta not. For short run ( in the heading of small changes ) it looks > just like all the other items (historically) commented out, but not yet > removed :) More things to clean up for the long run i guess. > So far as I know, var-args works fine on the other platforms. See ioctl in termios.c (w32) for instance. I would rather link to make_message or implement a work alike. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 20:49:44 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 22:49:44 -0500 Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: References: Message-ID: <475CB758.6000508@gatworks.com> rxtx-bounces at qbang.org wrote: > Your mail to 'Rxtx' with the subject > > Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al > > Is being held until the list moderator can review it for approval. I suppose this limitation was a recent change? :/ From tjarvi at qbang.org Sun Dec 9 20:55:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 20:55:33 -0700 (MST) Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: <475CB758.6000508@gatworks.com> References: <475CB758.6000508@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > > rxtx-bounces at qbang.org wrote: >> Your mail to 'Rxtx' with the subject >> >> Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al >> >> Is being held until the list moderator can review it for approval. > > > I suppose this limitation was a recent change? :/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > No. It is just a size limititation. I have upped it in the past. You might consider sending it as a .gz/.zip. Many people end up with full mailboxes and then bounce. The size limitation is 3 years old. The reason I don't get to the deffered email very often is it gets about 1k spams a week. At least we keep the spam out of everyones email box. If you like, I can fish out your email. I'd suggest zipping it though. There are ~500 people on the list but most just want to follow along. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 21:07:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 23:07:15 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: <475CBB73.9080805@gatworks.com> > So far as I know, var-args works fine on the other platforms. See ioctl > in termios.c (w32) for instance. > dont have a win32 development system. At least not a recent one. And not installed anywhere :}} > I would rather link to make_message or implement a work alike. Its not a problem. looks almost like the jprint( ... ). -------------- next part -------------- A non-text attachment was scrubbed... Name: IfDef_patch.gz Type: application/x-gzip Size: 10381 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/5a6ec2c1/attachment.gz From vorobyev.a at gmail.com Mon Dec 10 00:41:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 10:41:32 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475CEDAC.9090907@gmail.com> >2) change permissions to be RW for you group or owner. Thanks, it is my stupid mistake. But usb printer not work anyway. Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; ========================================== test program in c++: void ParallelPort::test(){ int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) return ; printf("status: 0x%02x\n",status); printf("Busy (~status & LP_PBUSY) : %x\n", (~status & LP_PBUSY)); printf("Error (~status & LP_PERRORP): %x\n", (~status & LP_PERRORP)); printf("Select (status & LP_PSELECD) : %x\n", (status & LP_PSELECD)); printf("Paper out (status & LP_POUTPA) : %x\n", (status & LP_POUTPA)); } result: status: 0x18 Busy (~status & LP_PBUSY) : 80 Error (~status & LP_PERRORP): 0 Select (status & LP_PSELECD) : 10 Paper out (status & LP_POUTPA) : 0 ParallelPort port("/dev/usblp0"); port.open(); port.write("Hello world"); port.write(0x1e); // cut port.close(); Result: Device print data and cut paper. ========================================== test program in java: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 50000); System.out.println("paper out: "+ port.isPaperOut()); System.out.println("buzy: "+ port.isPrinterBusy()); System.out.println("error: "+ port.isPrinterError()); System.out.println("select: "+ port.isPrinterSelected()); System.out.println("timeout: "+ port.isPrinterTimedOut()); result: paper out: true buzy: false error: false select: false timeout: false From netbeans at gatworks.com Sun Dec 9 22:04:46 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 00:04:46 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475CEDAC.9090907@gmail.com> References: <475CEDAC.9090907@gmail.com> Message-ID: <475CC8EE.9040205@gatworks.com> Alexander Vorobyev wrote: >> 2) change permissions to be RW for you group or owner. > Thanks, it is my stupid mistake. > > But usb printer not work anyway. > Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; I suppose the USB/LP driver may not be sophisticated enough to provide that information, presuming that information is at all relevant to the device itself ( like a parallel port Zip Drive ). From vorobyev.a at gmail.com Mon Dec 10 01:46:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 11:46:32 +0300 Subject: [Rxtx] One more question about usb->lpt Message-ID: <475CFCE8.3080807@gmail.com> Good day I wrote about the arisen problems at work with the device/dev/usb/lp0. At use c ++ work with the given device is made easily enough. Example void Usb2Lpt::open(){ handle = ::open(this->device.c_str(),O_RDWR|O_NOCTTY|O_NDELAY); if (handle<0) throw FileNotOpenException(strerror(errno)); } void Usb2Lpt::close(){ ::close(handle); handle = -1; } void Usb2Lpt::waitForRead(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, &rfds, NULL, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } void Usb2Lpt::waitForWrite(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, NULL, &rfds, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } unsigned char* Usb2Lpt::read(uint size){ .... r = ::read(handle,buf,len); ... return buf; } int Usb2Lpt::write(char data){ int w; waitForWrite(); w = ::write(handle,&data,sizeof(data)); if (w==-1){ if (errno==EAGAIN) return 0; else throw IOException(strerror(errno); } return w; } I.e. it is work as write/read + blocking/nonblocking mode; It is how much easy to make support of such driver in library rxtx? From zhouzhao58 at 163.com Mon Dec 10 05:13:14 2007 From: zhouzhao58 at 163.com (=?GBK?B?1tzuyA==?=) Date: Mon, 10 Dec 2007 20:13:14 +0800 (CST) Subject: [Rxtx] Help me ,please Message-ID: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> I used a common-user in the MAC OS 10.5. When i used rxtx 2.1.7 to open the serial port on the MAC OS 10.5.the rxtx has a error. how can I do ? thanks description: error testing lock file creation error details:permission deniedcheck_lock_status:no perminssion to create lock file. please see: how can I use lock files with rxtx ? in install -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/0ebc8026/attachment.html From dwippermann at gmx.net Mon Dec 10 05:29:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 13:29:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Hi again, > One other problem I see is the use of the ++/-- operators on a > variable that can be accessed by mutliple threads in parallel. I'll > run a short test tomorrow on my office machine, but I assume that > its read-modify-write behaviour might bring up a collision like: > > IOLocked = 100, both thread are running in different CPUs, but due > to timing arrive at the "IOLocked--" nearly simultaneously > > CPU 1: reads variable to register => register = 100 > CPU 2: doing something else > -- > CPU 1: decrements register => register = 99 > CPU 2: reads variable to register => register = 100 > -- > CPU 1: writes register to variable => variable = 99 > CPU 2: decrements register => register = 99 > -- > CPU 1: doing something else > CPU 2: writes register to variable => variable = 99 > > It should have decremented twice, but it didn't... Thats a common > situtation where locking is needed: modify the same variable from > different threads without synchonization is hell :) Small sample app: (((snip))) public class Main { static Object mutex; static int counter; public static void concurrencyTest(final boolean useMutex) { Runnable r = new Runnable() { public void run() { synchronized(mutex) { try { mutex.wait(); } catch (Exception ex) { ex.printStackTrace(); } } for (int i = 0; i < 1000000; i++) { if (useMutex) { synchronized (mutex) { counter++; } } else { counter++; } } } }; try { counter = 0; mutex = new Object(); Thread t1 = new Thread(r); Thread t2 = new Thread(r); // start the two threads, they will wait for the mutex to be signaled t1.start(); t2.start(); // just a little sleep before the work Thread.sleep(100); synchronized (mutex) { // signal the two threads to start working mutex.notifyAll(); } t1.join(); t2.join(); System.out.println("useMutex = " + useMutex + " => counter = " + counter); } catch (Exception ex) { ex.printStackTrace(); } } public static void main(String[] args) { concurrencyTest(true); concurrencyTest(false); } } (((snip))) The program starts two threads. Each thread should increment a counter 1 million times, hence you expect a result of 2 million. Haven't tested it on a single-core machine, but on my multi-core office machine I get: useMutex = true => counter = 2000000 useMutex = false => counter = 1221835 The second result is fluctuating heavily. By that example I want to demonstrate that the use of "IOLocked++" for locking purposes is by far not thread-safe. And if you have heavy trafiic over the serial port (as I have, up to 2,8 MB of data to transceive at 115kbps), the chance of synchronization issues is reasonable. The only possibility I have to counter this at the moment is to synchronize all function calls to RXTX, especially close(), getInputStream(), read() as well as getOutputStream() and write(). It cannot be taken as a general advise to solve this problem, because synchronization has to fit into thr rest of your app. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/99aca116/attachment-0001.html From netbeans at gatworks.com Mon Dec 10 06:59:29 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 08:59:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D4641.7050001@gatworks.com> > By that example I want to demonstrate that the use of "IOLocked++" for > locking purposes is by far not thread-safe. And if you have heavy > trafiic over the serial port (as I have, up to 2,8 MB of data to > transceive at 115kbps), the chance of synchronization issues is reasonable. Synchronization of read/writes should be handled by the user. There is nothing in rxtx that will disturb the synchronization, as it is not an rxtx function. If a user wants to have 3 threads writing to that device, its up to the user to coordinate the proper sequencing of writes. The synchronize reads in SerialImp/read() appear to be a violation of the abstract class InputStream. If you want 3 threads simultaneously reading from that device, then thats up to the users application to determine the sequence for access. The IOLocked is a flag to indicate that a read/write I/O operation is in progress. it does not lockout the other from happening simultaneously. The synchronize read() does prevent simultaneous reads from multiple threads. The IOLocked indicator does prevent the close() from starting up, as close() waits for the IOLock value to become 0. The presumption is that the application's reads/writes will cease because the application has issued a close(). You wouldnt issue any further I/O after the close - would you? From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0009.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0007.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0007.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0006.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0004.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment-0004.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From ajmas at sympatico.ca Sat Dec 8 08:13:26 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 8 Dec 2007 10:13:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> On 7-Dec-07, at 14:26 , Beat Arnet wrote: > > On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. > > > Well, that's certainly what you get when electrical engineers like > me write software ;) > > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > > > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. If you can you should assign the responsibility of closing the port to the one handling the port. The other thread should simply be telling the handling thread that it should close the port. Threads are like people, in that if you give them conflicting instructions all hell breaks loose. For example of what I think you should do: class MyClass { private boolean continueReading = true; public void run() { InputStream in = null; try { in = createMyInputStream(); // or however int len = 0; byte[] buffer = new byte[1024]; while ( (len = in.read(buffer)) > 0 && continueReading ) { // handle the read data } } catch ( IOException ex ) { } finally { if ( in != null ) { in.close(); } } } } Andre From netbeans at gatworks.com Sat Dec 8 16:25:43 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 08 Dec 2007 18:25:43 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: <475B27F7.5040500@gatworks.com> >> But I am not talking about multiple threads reading from the same >> port. I am dealing with a case in which one thread is reading from the >> port, and another wants to close the port. > So I looked at the RXTX code ( close(), read() ) ( is that what u were trying to point out ? ) and it seems that a close() may not close. If there is heavy reading, then maybe close wont happen at all. Not sure why read is synchronized. If someone wants to read - uncoordinated, then that his option! But the read() and the close() does not appear to have a strong method of synchronization ( close should set a flag, that would cause any further I/O requests to throw an exception ). On would think that a close() would also prevent any further write() operations. But it does not. It also does not appear to wait for the write( b[] ) to complete ( in case the array has to be written out in chunks bec the kernel buffer is full. ) Does this help any? :-} From vorobyev.a at gmail.com Sun Dec 9 01:31:05 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Sun, 09 Dec 2007 11:31:05 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475BA7C9.6090900@gmail.com> Good day. Following problem: Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Java 6 - 1.6.02 OS OpenSuse 10.3, 2.6.22.13-0.3-default I have attach USB printer: Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device found, idVendor=088c, idProduct=2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Product: TTP 2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Manufacturer: Swecoin AB Dec 8 09:25:46 linux-fceg kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x088C pid 0x2030 Dec 8 09:25:46 linux-fceg kernel: usbcore: registered new interface driver usblp Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver linux-fceg:/var/log # ll /dev/usb* lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 Example: Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { CommPortIdentifier portIdentifier = (CommPortIdentifier) portEnum.nextElement(); System.out.println(portIdentifier.getName() + " - " + getPortTypeName(portIdentifier.getPortType())); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial Virtual LPT port not found... Parallel port /dev/lp0 not foud also. After that i modified source RXTXCommDriver.java, registerScannedPorts if (osName.equals("Linux") { String[] temp = { "lp", // linux printer port "usblp" <====================== add this }; CandidatePortPrefixes = temp; } else if (osName.equals("FreeBSD")) { But /dev/usblp0 not found anyway. After that i modified registerValidPorts if (osName.equals("Solaris") || osName.equals("SunOS")) { checkSolaris(PortName, PortType); } else { if (PortType==CommPortIdentifier.PORT_PARALLEL) <<<< i.e. port type is parallel - don't execute testRead CommPortIdentifier.addPortName( PortName,PortType,this); <<<< else if (testRead(PortName, PortType)) CommPortIdentifier.addPortName( PortName,PortType,this); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial /dev/usblp0 - Parallel /dev/lp0 - Parallel I think, what native testRead incorrectly defines presence of parallel port. I think that presence parallel port can be checked up so: int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) // port is not exist or it is not parallel port else // port is parallel! After that i execute program: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 5000); String str = "12313212312313121231321231231312"; port.getOutputStream().write(str.getBytes()); port.close(); Result: RXTXCommDriver:getCommPort(/dev/usblp0,2) LPRPort:LPRPort(/dev/usblp0) Port /dev/usblp0 in use by another application gnu.io.PortInUseException: Unknown Linux Application linux-fceg:/var/log # lsof | grep /dev/usb I.e. port is not use. Similar result at use /dev/lp0 How i can use parallel ports in my program? PS: Sorry for my english :) From tjarvi at qbang.org Sun Dec 9 00:03:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 00:03:51 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: On Sat, 8 Dec 2007, U. George wrote: >>> But I am not talking about multiple threads reading from the same >>> port. I am dealing with a case in which one thread is reading from the >>> port, and another wants to close the port. >> > So I looked at the RXTX code ( close(), read() ) ( is that what u were > trying to point out ? ) and it seems that a close() may not close. If > there is heavy reading, then maybe close wont happen at all. > > Not sure why read is synchronized. If someone wants to read - > uncoordinated, then that his option! > But the read() and the close() does not appear to have a strong method > of synchronization ( close should set a flag, that would cause any > further I/O requests to throw an exception ). > > On would think that a close() would also prevent any further write() > operations. But it does not. It also does not appear to wait for the > write( b[] ) to complete ( in case the array has to be written out in > chunks bec the kernel buffer is full. ) > Hi George, The code may not look conventional because I wasnt looking at other code at the time. It does do close to what you expect. The code got there the hard way though. close sets the fd to 0 which should throw exceptions if you try IO. while( IOLocked > 0 ) should delay close while reading and writing are in progress. In write(b[]) the following code can be found (comments added): // throw exception if closed. if ( fd == 0 ) throw new IOException(); // prevent closing while writing. IOLocked++; // Ensure the event thread is not being setup. ie // open() waitForTheNativeCodeSilly(); read() has the same logic (deleting some code for clairity) if ( fd == 0 ) throw new IOException(); IOLocked++; waitForTheNativeCodeSilly(); The close(): (for clairity just the code that we care about here:) while( IOLocked > 0 ) { sleep() } removeEventListener(); nativeClose( this.name ); fd = 0; -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 03:35:47 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 05:35:47 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475BA7C9.6090900@gmail.com> References: <475BA7C9.6090900@gmail.com> Message-ID: <475BC503.7010708@gatworks.com> > > linux-fceg:/var/log # ll /dev/usb* > lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 I suppose this is your first issue i would have expected a /dev/usblp0 ->/dev/lp1 ( since most machines have a /dev/lp0 ) > > result: > /dev/ttyS2 - Serial > /dev/ttyS1 - Serial > /dev/ttyS0 - Serial > Virtual LPT port not found... Parallel port /dev/lp0 not foud also. thats bec lp0 its in /dev/usb ! > > LPRPort:LPRPort(/dev/usblp0) > Port /dev/usblp0 in use by another application > gnu.io.PortInUseException: Unknown Linux Application rxtx code: int fd = open( filename, O_RDWR | O_NONBLOCK ); rxtx appears to want to be able to open the device for reading AND writing. I suspect permission failure. 1) anyway have a symbolic pointer from /dev/usb/usblp0 to /dev/lp0 2) change permissions to be RW for you group or owner. From netbeans at gatworks.com Sun Dec 9 04:44:35 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 06:44:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <475BD523.3000900@gatworks.com> > close sets the fd to 0 which should throw exceptions if you try IO. Setting fd to 0 appears to be the last step in rxtx-close. It should be the first step, as a mutex to prevent any further I/O to the channel. With hyperthreads, quad cpu's, other threads can be simultaneously ( in real time ) executing reads & writes & other things. > > while( IOLocked > 0 ) should delay close while reading and writing are > in progress. Yes, but there is nothing there to prevent any further user I/O. You could have a bunch of threads continue to read & write, and keep IOLock > 0 for some time. Even if it did reach IOLock reached 0, there is still the possibility of some thread upping IOLock inbetween. > > In write(b[]) the following code can be found (comments added): > > // throw exception if closed. > if ( fd == 0 ) throw new IOException(); > // prevent closing while writing. Where is the "prevent further writing while closing" ? > > (for clairity just the code that we care about here:) > > while( IOLocked > 0 ) > { sleep() } this can take a long time to process. And defeats the purpose of a close() at time x. Because at time x+1, any further user requests to that file descriptor should have failed. One also has to ask why is the user program still reading or writing after having the close() called? But that is for the user to figure out. The orig question posed was to have a multi cpu, and 2 java threads. 1 thread was reading, while the other was ( attempting to ) closeing. probably something like this should be done: public close() { synchonize( eis ) { we_are_closing_up = true; while ( IOLock > 0 ) sleep( 100ms ); } native_close(); fd = 0; } we_are_closing_up = false; } public write() { if ( we_are_closing_up ) synchronize( eis ) { ; } if ( fd == 0 ) throw ( ..... IOLock++; ...... this is also not perfect. There is the possibility that a close could happen after the test, and before the IOLock++ From beat.arnet at gmail.com Sun Dec 9 05:44:23 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 09 Dec 2007 07:44:23 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475BE327.9010709@gmail.com> Thanks to all for responding to my original question! From what I hear, we now suspect that some improvements in RXTX might be necessary to make the code 100% thread safe. I would be happy to help, but I fear that I might not quite have the necessary training/skills. Maybe with some guidance I could give it a try. Since there has been no official release since 2.1.7, I am also wondering where I should start in the trunk so that I can be sure that all valid bug fixes that have been submitted sine 2.1.7 are included. However, I would also like to find out if there is something short-term that I can do in my application to avoid dead-locks on dual core machines, before RXTX is fixed. After Daniel's response, I synchronized all RXTXPort accesses, but I have still some crashes being reported from the field, albeit much less (and possibly unrelated?). Should I setup my code such that all accesses to the serial port happen in one unique thread? Would this prevent the problems that are described below? Any further guidance from the group would be appreciated. Regards, Beat U. George wrote: >> close sets the fd to 0 which should throw exceptions if you try IO. >> > Setting fd to 0 appears to be the last step in rxtx-close. It should be > the first step, as a mutex to prevent any further I/O to the channel. > With hyperthreads, quad cpu's, other threads can be simultaneously ( in > real time ) executing reads & writes & other things. > > > >> while( IOLocked > 0 ) should delay close while reading and writing are >> in progress. >> > Yes, but there is nothing there to prevent any further user I/O. You > could have a bunch of threads continue to read & write, and keep IOLock > > 0 for some time. > Even if it did reach IOLock reached 0, there is still the possibility of > some thread upping IOLock inbetween. > >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. >> > Where is the "prevent further writing while closing" ? > >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } >> > this can take a long time to process. And defeats the purpose of a > close() at time x. Because at time x+1, any further user requests to > that file descriptor should have failed. > One also has to ask why is the user program still reading or writing > after having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/6b16e64b/attachment-0003.html From tjarvi at qbang.org Sun Dec 9 11:01:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 11:01:00 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > >> close sets the fd to 0 which should throw exceptions if you try IO. > Setting fd to 0 appears to be the last step in rxtx-close. It should be the > first step, as a mutex to prevent any further I/O to the channel. With > hyperthreads, quad cpu's, other threads can be simultaneously ( in real time > ) executing reads & writes & other things. > > >> >> while( IOLocked > 0 ) should delay close while reading and writing are in >> progress. > Yes, but there is nothing there to prevent any further user I/O. You could > have a bunch of threads continue to read & write, and keep IOLock > 0 for > some time. > Even if it did reach IOLock reached 0, there is still the possibility of some > thread upping IOLock inbetween. >> >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. > Where is the "prevent further writing while closing" ? >> >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } > this can take a long time to process. And defeats the purpose of a close() at > time x. Because at time x+1, any further user requests to that file > descriptor should have failed. > One also has to ask why is the user program still reading or writing after > having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 thread > was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could happen > after the test, and before the IOLock++ > There are two questions in the back of my mind. The first is I'd like to see some form of documentation in the Java API that says this is the right behavior. Anything from file IO to network sockets. The second is that we are dealing with perhaps the slowest reads and writes out there. I'd anticipate some downstream impact (incompatability) with people using the current implementation. At least at first, a change like this should be something people opt into via preferences or other means. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 12:17:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 14:17:15 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C3F3B.9050003@gatworks.com> > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. ?? I'm not sure what behavior your are expecting the JAVA docs to explain? I'd be more interested in the OS docs that will/could explain the interaction of threads and the sequencing of I/O operations amongst active cpu instruction pipelines. > > The second is that we are dealing with perhaps the slowest reads and > writes out there. I'd anticipate some downstream impact > (incompatability) with people using the current implementation. At > least at first, a change like this should be something people opt into > via preferences or other means. u mean there are folks that continue to read & write even though they also issued a (premature) close ? I am not aware of any OS that behaves like that. Or allows that. Yes, but if you will notice, the the speed of USB devices, that are made to behave like serial, or parallel devices, are very-very fast. A 500ms sleep is forever on some USB devices. BTW: Since JAVA source went public, sorta, did java publish the commapi source? BTW#2:Your mail to 'Rxtx' with the subject If not DEBUGing, remove useless calls to report() et al Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 46243 bytes with a limit of 40 KB From netbeans at gatworks.com Sun Dec 9 13:00:09 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 15:00:09 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C4949.5060109@gatworks.com> > > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. from Class CommPort: After a communications port has been identified and opened it can be configured with the methods in the low-level classes like SerialPort and ParallelPort. Then an IO stream can be opend for reading and writing data. Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown. From dwippermann at gmx.net Sun Dec 9 13:36:28 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:36:28 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: Hi all, > If you can you should assign the responsibility of closing the port > to the one > handling the port. The other thread should simply be telling the > handling thread > that it should close the port. Threads are like people, in that if > you give them > conflicting instructions all hell breaks loose. For example of what > I think you > should do: > yes, that you be the common way if I had full control over the thread. But the thread is implemented and started by RXTX, I only get event through my listener. How should the listener be able to close the port if no event is triggered? Can I wake up the RXTX thread to send a dummy event to trigger the close from inside the listener? Daniel From dwippermann at gmx.net Sun Dec 9 13:55:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:55:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: And hi once more, > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ Thats the reason why I encapsulated all access in synchronized blocks using one mutex. You simply have no problem with "after ... , but before..." anymore :) One other problem I see is the use of the ++/-- operators on a variable that can be accessed by mutliple threads in parallel. I'll run a short test tomorrow on my office machine, but I assume that its read-modify-write behaviour might bring up a collision like: IOLocked = 100, both thread are running in different CPUs, but due to timing arrive at the "IOLocked--" nearly simultaneously CPU 1: reads variable to register => register = 100 CPU 2: doing something else -- CPU 1: decrements register => register = 99 CPU 2: reads variable to register => register = 100 -- CPU 1: writes register to variable => variable = 99 CPU 2: decrements register => register = 99 -- CPU 1: doing something else CPU 2: writes register to variable => variable = 99 It should have decremented twice, but it didn't... Thats a common situtation where locking is needed: modify the same variable from different threads without synchonization is hell :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/4bd9d474/attachment-0002.html From netbeans at gatworks.com Thu Dec 6 04:14:53 2007 From: netbeans at gatworks.com (U. George) Date: Thu, 06 Dec 2007 06:14:53 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al Message-ID: <4757D9AD.2080305@gatworks.com> For the most part the report() calls from everywhere is usefull in debugging whats happening within rxtx. BUT if you are not debugging, then it is just wasted CPU cycles. That also includes the sprintf's sprinkled here and there. I placed the DEBUG code ( SerialImp.c ) under the #ifdef DEBUG . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071206/92c448eb/attachment-0002.pl From tjarvi at qbang.org Sun Dec 9 19:15:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:15:44 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <4757D9AD.2080305@gatworks.com> References: <4757D9AD.2080305@gatworks.com> Message-ID: This looks OK to me George. Just two issues. make_message is probably copyrighted by the Free Software Foundation. It is probably easier to recode it than deal with the minor potential issues. The only other minor issue is that commenting out code isn't really better than deleting it in the long run. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 19:35:41 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 21:35:41 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> Message-ID: <475CA5FD.6050801@gatworks.com> Trent Jarvi wrote: > > This looks OK to me George. Just two issues. > > make_message is probably copyrighted by the Free Software Foundation. > It is probably easier to recode it than deal with the minor potential > issues. code u refer to is not used. I'm not too sure if "all" cc/libs can handle the particular var-args scheme. So if blows up, then that becomes an issue, but not harmfull for anybody's run. I did want to use it to do: REPORT("FIONREAD failed with error %s\n", strerror( errno )); or more recently REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); Since u PORT this to other machines, its not clear if var-args works everywhere the same way. u got any notion? > > The only other minor issue is that commenting out code isn't really > better than deleting it in the long run. > Sorta, sorta not. For short run ( in the heading of small changes ) it looks just like all the other items (historically) commented out, but not yet removed :) More things to clean up for the long run i guess. From tjarvi at qbang.org Sun Dec 9 19:47:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:47:37 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <475CA5FD.6050801@gatworks.com> References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> >> This looks OK to me George. Just two issues. >> >> make_message is probably copyrighted by the Free Software Foundation. It >> is probably easier to recode it than deal with the minor potential issues. > code u refer to is not used. I'm not too sure if "all" cc/libs can handle the > particular var-args scheme. So if blows up, then that becomes an issue, but > not harmfull for anybody's run. > > I did want to use it to do: > REPORT("FIONREAD failed with error %s\n", strerror( errno )); > > or more recently > > REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); > > Since u PORT this to other machines, its not clear if var-args works > everywhere the same way. u got any notion? > >> >> The only other minor issue is that commenting out code isn't really better >> than deleting it in the long run. >> > Sorta, sorta not. For short run ( in the heading of small changes ) it looks > just like all the other items (historically) commented out, but not yet > removed :) More things to clean up for the long run i guess. > So far as I know, var-args works fine on the other platforms. See ioctl in termios.c (w32) for instance. I would rather link to make_message or implement a work alike. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 20:49:44 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 22:49:44 -0500 Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: References: Message-ID: <475CB758.6000508@gatworks.com> rxtx-bounces at qbang.org wrote: > Your mail to 'Rxtx' with the subject > > Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al > > Is being held until the list moderator can review it for approval. I suppose this limitation was a recent change? :/ From tjarvi at qbang.org Sun Dec 9 20:55:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 20:55:33 -0700 (MST) Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: <475CB758.6000508@gatworks.com> References: <475CB758.6000508@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > > rxtx-bounces at qbang.org wrote: >> Your mail to 'Rxtx' with the subject >> >> Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al >> >> Is being held until the list moderator can review it for approval. > > > I suppose this limitation was a recent change? :/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > No. It is just a size limititation. I have upped it in the past. You might consider sending it as a .gz/.zip. Many people end up with full mailboxes and then bounce. The size limitation is 3 years old. The reason I don't get to the deffered email very often is it gets about 1k spams a week. At least we keep the spam out of everyones email box. If you like, I can fish out your email. I'd suggest zipping it though. There are ~500 people on the list but most just want to follow along. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 21:07:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 23:07:15 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: <475CBB73.9080805@gatworks.com> > So far as I know, var-args works fine on the other platforms. See ioctl > in termios.c (w32) for instance. > dont have a win32 development system. At least not a recent one. And not installed anywhere :}} > I would rather link to make_message or implement a work alike. Its not a problem. looks almost like the jprint( ... ). -------------- next part -------------- A non-text attachment was scrubbed... Name: IfDef_patch.gz Type: application/x-gzip Size: 10381 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/5a6ec2c1/attachment-0002.gz From vorobyev.a at gmail.com Mon Dec 10 00:41:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 10:41:32 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475CEDAC.9090907@gmail.com> >2) change permissions to be RW for you group or owner. Thanks, it is my stupid mistake. But usb printer not work anyway. Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; ========================================== test program in c++: void ParallelPort::test(){ int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) return ; printf("status: 0x%02x\n",status); printf("Busy (~status & LP_PBUSY) : %x\n", (~status & LP_PBUSY)); printf("Error (~status & LP_PERRORP): %x\n", (~status & LP_PERRORP)); printf("Select (status & LP_PSELECD) : %x\n", (status & LP_PSELECD)); printf("Paper out (status & LP_POUTPA) : %x\n", (status & LP_POUTPA)); } result: status: 0x18 Busy (~status & LP_PBUSY) : 80 Error (~status & LP_PERRORP): 0 Select (status & LP_PSELECD) : 10 Paper out (status & LP_POUTPA) : 0 ParallelPort port("/dev/usblp0"); port.open(); port.write("Hello world"); port.write(0x1e); // cut port.close(); Result: Device print data and cut paper. ========================================== test program in java: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 50000); System.out.println("paper out: "+ port.isPaperOut()); System.out.println("buzy: "+ port.isPrinterBusy()); System.out.println("error: "+ port.isPrinterError()); System.out.println("select: "+ port.isPrinterSelected()); System.out.println("timeout: "+ port.isPrinterTimedOut()); result: paper out: true buzy: false error: false select: false timeout: false From netbeans at gatworks.com Sun Dec 9 22:04:46 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 00:04:46 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475CEDAC.9090907@gmail.com> References: <475CEDAC.9090907@gmail.com> Message-ID: <475CC8EE.9040205@gatworks.com> Alexander Vorobyev wrote: >> 2) change permissions to be RW for you group or owner. > Thanks, it is my stupid mistake. > > But usb printer not work anyway. > Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; I suppose the USB/LP driver may not be sophisticated enough to provide that information, presuming that information is at all relevant to the device itself ( like a parallel port Zip Drive ). From vorobyev.a at gmail.com Mon Dec 10 01:46:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 11:46:32 +0300 Subject: [Rxtx] One more question about usb->lpt Message-ID: <475CFCE8.3080807@gmail.com> Good day I wrote about the arisen problems at work with the device/dev/usb/lp0. At use c ++ work with the given device is made easily enough. Example void Usb2Lpt::open(){ handle = ::open(this->device.c_str(),O_RDWR|O_NOCTTY|O_NDELAY); if (handle<0) throw FileNotOpenException(strerror(errno)); } void Usb2Lpt::close(){ ::close(handle); handle = -1; } void Usb2Lpt::waitForRead(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, &rfds, NULL, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } void Usb2Lpt::waitForWrite(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, NULL, &rfds, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } unsigned char* Usb2Lpt::read(uint size){ .... r = ::read(handle,buf,len); ... return buf; } int Usb2Lpt::write(char data){ int w; waitForWrite(); w = ::write(handle,&data,sizeof(data)); if (w==-1){ if (errno==EAGAIN) return 0; else throw IOException(strerror(errno); } return w; } I.e. it is work as write/read + blocking/nonblocking mode; It is how much easy to make support of such driver in library rxtx? From zhouzhao58 at 163.com Mon Dec 10 05:13:14 2007 From: zhouzhao58 at 163.com (=?GBK?B?1tzuyA==?=) Date: Mon, 10 Dec 2007 20:13:14 +0800 (CST) Subject: [Rxtx] Help me ,please Message-ID: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> I used a common-user in the MAC OS 10.5. When i used rxtx 2.1.7 to open the serial port on the MAC OS 10.5.the rxtx has a error. how can I do ? thanks description: error testing lock file creation error details:permission deniedcheck_lock_status:no perminssion to create lock file. please see: how can I use lock files with rxtx ? in install -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/0ebc8026/attachment-0002.html From dwippermann at gmx.net Mon Dec 10 05:29:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 13:29:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Hi again, > One other problem I see is the use of the ++/-- operators on a > variable that can be accessed by mutliple threads in parallel. I'll > run a short test tomorrow on my office machine, but I assume that > its read-modify-write behaviour might bring up a collision like: > > IOLocked = 100, both thread are running in different CPUs, but due > to timing arrive at the "IOLocked--" nearly simultaneously > > CPU 1: reads variable to register => register = 100 > CPU 2: doing something else > -- > CPU 1: decrements register => register = 99 > CPU 2: reads variable to register => register = 100 > -- > CPU 1: writes register to variable => variable = 99 > CPU 2: decrements register => register = 99 > -- > CPU 1: doing something else > CPU 2: writes register to variable => variable = 99 > > It should have decremented twice, but it didn't... Thats a common > situtation where locking is needed: modify the same variable from > different threads without synchonization is hell :) Small sample app: (((snip))) public class Main { static Object mutex; static int counter; public static void concurrencyTest(final boolean useMutex) { Runnable r = new Runnable() { public void run() { synchronized(mutex) { try { mutex.wait(); } catch (Exception ex) { ex.printStackTrace(); } } for (int i = 0; i < 1000000; i++) { if (useMutex) { synchronized (mutex) { counter++; } } else { counter++; } } } }; try { counter = 0; mutex = new Object(); Thread t1 = new Thread(r); Thread t2 = new Thread(r); // start the two threads, they will wait for the mutex to be signaled t1.start(); t2.start(); // just a little sleep before the work Thread.sleep(100); synchronized (mutex) { // signal the two threads to start working mutex.notifyAll(); } t1.join(); t2.join(); System.out.println("useMutex = " + useMutex + " => counter = " + counter); } catch (Exception ex) { ex.printStackTrace(); } } public static void main(String[] args) { concurrencyTest(true); concurrencyTest(false); } } (((snip))) The program starts two threads. Each thread should increment a counter 1 million times, hence you expect a result of 2 million. Haven't tested it on a single-core machine, but on my multi-core office machine I get: useMutex = true => counter = 2000000 useMutex = false => counter = 1221835 The second result is fluctuating heavily. By that example I want to demonstrate that the use of "IOLocked++" for locking purposes is by far not thread-safe. And if you have heavy trafiic over the serial port (as I have, up to 2,8 MB of data to transceive at 115kbps), the chance of synchronization issues is reasonable. The only possibility I have to counter this at the moment is to synchronize all function calls to RXTX, especially close(), getInputStream(), read() as well as getOutputStream() and write(). It cannot be taken as a general advise to solve this problem, because synchronization has to fit into thr rest of your app. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/99aca116/attachment-0002.html From netbeans at gatworks.com Mon Dec 10 06:59:29 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 08:59:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D4641.7050001@gatworks.com> > By that example I want to demonstrate that the use of "IOLocked++" for > locking purposes is by far not thread-safe. And if you have heavy > trafiic over the serial port (as I have, up to 2,8 MB of data to > transceive at 115kbps), the chance of synchronization issues is reasonable. Synchronization of read/writes should be handled by the user. There is nothing in rxtx that will disturb the synchronization, as it is not an rxtx function. If a user wants to have 3 threads writing to that device, its up to the user to coordinate the proper sequencing of writes. The synchronize reads in SerialImp/read() appear to be a violation of the abstract class InputStream. If you want 3 threads simultaneously reading from that device, then thats up to the users application to determine the sequence for access. The IOLocked is a flag to indicate that a read/write I/O operation is in progress. it does not lockout the other from happening simultaneously. The synchronize read() does prevent simultaneous reads from multiple threads. The IOLocked indicator does prevent the close() from starting up, as close() waits for the IOLock value to become 0. The presumption is that the application's reads/writes will cease because the application has issued a close(). You wouldnt issue any further I/O after the close - would you? From dwippermann at gmx.net Mon Dec 10 07:53:03 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 15:53:03 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi all, > The IOLocked is a flag to indicate that a read/write I/O operation > is in > progress. it does not lockout the other from happening simultaneously. > The synchronize read() does prevent simultaneous reads from multiple > threads. > The IOLocked indicator does prevent the close() from starting up, as > close() waits for the IOLock value to become 0. The presumption is > that > the application's reads/writes will cease because the application has > issued a close(). You wouldnt issue any further I/O after the close - > would you? You are completely right, I never meant to imply something different. The IOLocked shall not lock concurrent reads or concurrents writes away, but be a signal for the close method that some read or write is still underway and it has to wait for them to finish. But the original question was, why the IOLocked variable has a value ! = 0 ALTHOUGH all read and write activities have ceased quite a while ago? And there were only two threads involved: on one side the thread that called open() and write() and on the other side the RXTX monitor thread that calling read(). No multiple reads or writes! Only a parallel write while reading. But that cannot be forbidden since we talk about an USART. Or am I wrong? Is there a problem to to have one read() and one write() run simulatenously? If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/db7e990f/attachment.html From netbeans at gatworks.com Mon Dec 10 10:17:26 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 12:17:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D74A6.4000209@gatworks.com> > If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). i suppose u mean that the IOLocked++, and the IOLocked-- has to be accomplished atomically ? I suppose besides meaning that you would also like that? :} From dwippermann at gmx.net Mon Dec 10 10:22:40 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:22:40 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi everone, > Hi all, >> The IOLocked is a flag to indicate that a read/write I/O operation >> is in >> progress. it does not lockout the other from happening >> simultaneously. >> The synchronize read() does prevent simultaneous reads from multiple >> threads. >> The IOLocked indicator does prevent the close() from starting up, as >> close() waits for the IOLock value to become 0. The presumption is >> that >> the application's reads/writes will cease because the application has >> issued a close(). You wouldnt issue any further I/O after the close - >> would you? > You are completely right, I never meant to imply something > different. The IOLocked shall not lock concurrent reads or > concurrents writes away, but be a signal for the close method that > some read or write is still underway and it has to wait for them to > finish. > But the original question was, why the IOLocked variable has a > value != 0 ALTHOUGH all read and write activities have ceased quite > a while ago? And there were only two threads involved: on one side > the thread that called open() and write() and on the other side the > RXTX monitor thread that calling read(). No multiple reads or > writes! Only a parallel write while reading. But that cannot be > forbidden since we talk about an USART. Or am I wrong? Is there a > problem to to have one read() and one write() run simulatenously? > If that case is an allowed one, IOLocked has to be synchronized > because it is altered in read() and write(). I've prepared a patch to RXTXPort.java to help me outline my point of view in this discussion. It's attached to this posting. In general, three things have been done: 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be passed as a parameter to the synchronized statement. 2) Every "IOLocked++" is encapsulated by that said synchronized block 3) In some methods there were multiple "IOLocked--". Those have all been substituted by a one synchronized "IOLocked--" which is processed in a "finally" statement that handles all exceptions from right after "IOLocked++" till the end of the method. So every occurence or variation of the sequence: > IOLocked++; > waitForTheNativeCodeSilly(); > try { > // something method specific here > } catch (IOException ex) { > IOLocked--; > throw ex; > } > IOLocked--; has been replaced by: > synchronized (IOLockedMutex) { > IOLocked++; > } > try { > waitForTheNativeCodeSilly(); > // something method specific here > } finally { > synchronized (IOLockedMutex) { > IOLocked--; > } > } In my opinion that chance has no impact on the surrounding application. It wont block away one function call if another one is running, it only ensures, that only one thread alters the IOLocked variable at any given time. So you could have one polling read() and one write() action in parallel without interference. In the hope, that I haven't abused your patience too much :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RXTXPort_IOLockedMutex.diff Type: application/octet-stream Size: 6297 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0001.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0003.html From dwippermann at gmx.net Mon Dec 10 10:44:17 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:44:17 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Hi! > i suppose u mean that the IOLocked++, and the IOLocked-- has to be > accomplished atomically ? > > I suppose besides meaning that you would also like that? :} Yes, indeed... I was lacking the word "atomically", but at least you were able to follow my remaining semi-english explanation :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/5f88033d/attachment.html From netbeans at gatworks.com Mon Dec 10 14:03:38 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 16:03:38 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DA9AA.90106@gatworks.com> According to this (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): > A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking. It appears that "volatile" makes concurrent updates atomic. Its not intuitive. So is it true ? Daniel Wippermann wrote: > Hi! > >> i suppose u mean that the IOLocked++, and the IOLocked-- has to be >> accomplished atomically ? >> >> I suppose besides meaning that you would also like that? :} > Yes, indeed... I was lacking the word "atomically", but at least you > were able to follow my remaining semi-english explanation :) > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dwippermann at gmx.net Mon Dec 10 14:33:02 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 22:33:02 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: Hi, > According to this > (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html > ): > > A write to a volatile field happens-before every subsequent read > of that same field. Writes and reads of volatile fields have similar > memory consistency effects as entering and exiting monitors, but do > not entail mutual exclusion locking. > > It appears that "volatile" makes concurrent updates atomic. Its not > intuitive. So is it true ? > I tried the volatile declaration on my small ConcurrencyTest app. It has no effect, the unsynchronized version still misses a vast amount of increments. I think that the read-modify-write behaviour of "++" and "--" is not covered by the "happens-before" clause of the volatile declaration. It only ensures, that the corresponding read and write operations are not interrupted, the time in between these operations is not covered. Although it sounded promising on the first look... I can't imagine a different working approach to get IOLocked thread- safe at the moment. But perhaps I'm stuck and just have to think about it another night or two... Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/d13a0db5/attachment.html From netbeans at gatworks.com Mon Dec 10 15:32:42 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 17:32:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DBE8A.8050408@gatworks.com> I suspect that what they said is not exact. My impression, at one time, was that the volatile object could not be optimized into not writing to memory. Oh well. Have you tried java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? from jdk1.5 and beyond? these set of utilities have an interesting way of 'atomically' incrementing the variable. I'd be curious if your test would also fail using these utilities. Daniel Wippermann wrote: > Hi, > >> According to this >> (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): >> >/ A write to a volatile field happens-before every subsequent read of >> that same field. Writes and reads of volatile fields have similar >> memory consistency effects as entering and exiting monitors, but do >> not entail mutual exclusion locking. / It appears that "volatile" >> makes concurrent updates atomic. Its not intuitive. So is it true ? > > > I tried the volatile declaration on my small ConcurrencyTest app. It has > no effect, the unsynchronized version still misses a vast amount of > increments. > > I think that the read-modify-write behaviour of "++" and "--" is not > covered by the "happens-before" clause of the volatile declaration. It > only ensures, that the corresponding read and write operations are not > interrupted, the time in between these operations is not covered. > Although it sounded promising on the first look... > > I can't imagine a different working approach to get IOLocked thread-safe > at the moment. But perhaps I'm stuck and just have to think about it > another night or two... > > Daniel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com.cn Mon Dec 10 19:22:23 2007 From: zhanglong at adventnet.com.cn (zl) Date: Tue, 11 Dec 2007 10:22:23 +0800 Subject: [Rxtx] Homestay 2008 Beijing Olympic Message-ID: <475DF45F.5030702@adventnet.com.cn> Do you want to come to Beijing for 2008 Olympic? Please choose homestay for your accommodation and select my home. Introduction: The whole apartment is furnished in traditional Chinese Style. All furniture is brand new. There are two bedrooms, a modern kitchen, a living room, one bathrooms and one storageroom. It has all the gadgets and amenities including ADSL internet connection, on-demand cable, washer, fridge, microwave, a 25 inch television set, home security system.And community body guard is also included. 24 hours hot water services, local banking facilities,air conditioners are available. Everything is comfortable for living, also supermarket(Carrefour is 5 minuters), park, school, restaurants, entertainment places is surrounding. It's about 10 minutes' drive to the National Stadium (the Bird Nest), and no longer than 5 minutes' walk to the Olympics Forest Park. The subway line 13 and 5 's station of Lishuiqiao is 5-10 minutes' walking distance. For more detail and pictures,Please look at: http://picasaweb.google.com/zlong6688/HomestayBeijing2008 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249599243132994 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249629307904114 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096615126729827426 Contact me: E-mail: zhanglong at adventnet.com.cn Mobile: 13241969320 MSN:zlong6666 at hotmail.com PS: Please help me tell this message to your friends. And you can post this message with no limit. (End) ------------------------------------------------- From dwippermann at gmx.net Mon Dec 10 22:02:59 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 06:02:59 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Hi, > I suspect that what they said is not exact. My impression, at one > time, > was that the volatile object could not be optimized into not writing > to > memory. Oh well. > > Have you tried > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? > from jdk1.5 and beyond? > > these set of utilities have an interesting way of 'atomically' > incrementing the variable. I'd be curious if your test would also fail > using these utilities. thanks for that hint, an interesting package :) This class works as expected and is way faster (at least on my machine) that synchronizing the increment manually. The only drawback - as you mentioned before - is that it requires Java5 to run... And as far as I understand, RXTX targets 1.3 and later JREs... But an eyecatcher indeed, thanks again. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/376692e5/attachment.html From netbeans at gatworks.com Tue Dec 11 05:28:29 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 07:28:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Message-ID: <475E826D.40609@gatworks.com> u didnt catch it all. although introduced in 1.5, those same folks ( not sun ) who made that stuff public domain, also created a 1.4 version, and a 1.3 version. Those backward compatable routines are 'synchronize'd, so should run no better that what rxtx is currently doing. BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx synchronize directives be completely removed from reads and writes ( as well as the removal of IOLocked et al ) ? Daniel Wippermann wrote: > Hi, > >> I suspect that what they said is not exact. My impression, at one time, >> was that the volatile object could not be optimized into not writing to >> memory. Oh well. >> >> Have you tried >> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? >> from jdk1.5 and beyond? >> >> these set of utilities have an interesting way of 'atomically' >> incrementing the variable. I'd be curious if your test would also fail >> using these utilities. > > thanks for that hint, an interesting package :) > > This class works as expected and is way faster (at least on my machine) > that synchronizing the increment manually. > > The only drawback - as you mentioned before - is that it requires Java5 > to run... And as far as I understand, RXTX targets 1.3 and later JREs... > > But an eyecatcher indeed, thanks again. > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0010.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0008.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0008.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0007.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0005.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment-0005.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From ajmas at sympatico.ca Sat Dec 8 08:13:26 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 8 Dec 2007 10:13:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> On 7-Dec-07, at 14:26 , Beat Arnet wrote: > > On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. > > > Well, that's certainly what you get when electrical engineers like > me write software ;) > > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > > > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. If you can you should assign the responsibility of closing the port to the one handling the port. The other thread should simply be telling the handling thread that it should close the port. Threads are like people, in that if you give them conflicting instructions all hell breaks loose. For example of what I think you should do: class MyClass { private boolean continueReading = true; public void run() { InputStream in = null; try { in = createMyInputStream(); // or however int len = 0; byte[] buffer = new byte[1024]; while ( (len = in.read(buffer)) > 0 && continueReading ) { // handle the read data } } catch ( IOException ex ) { } finally { if ( in != null ) { in.close(); } } } } Andre From netbeans at gatworks.com Sat Dec 8 16:25:43 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 08 Dec 2007 18:25:43 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: <475B27F7.5040500@gatworks.com> >> But I am not talking about multiple threads reading from the same >> port. I am dealing with a case in which one thread is reading from the >> port, and another wants to close the port. > So I looked at the RXTX code ( close(), read() ) ( is that what u were trying to point out ? ) and it seems that a close() may not close. If there is heavy reading, then maybe close wont happen at all. Not sure why read is synchronized. If someone wants to read - uncoordinated, then that his option! But the read() and the close() does not appear to have a strong method of synchronization ( close should set a flag, that would cause any further I/O requests to throw an exception ). On would think that a close() would also prevent any further write() operations. But it does not. It also does not appear to wait for the write( b[] ) to complete ( in case the array has to be written out in chunks bec the kernel buffer is full. ) Does this help any? :-} From vorobyev.a at gmail.com Sun Dec 9 01:31:05 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Sun, 09 Dec 2007 11:31:05 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475BA7C9.6090900@gmail.com> Good day. Following problem: Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Java 6 - 1.6.02 OS OpenSuse 10.3, 2.6.22.13-0.3-default I have attach USB printer: Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device found, idVendor=088c, idProduct=2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Product: TTP 2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Manufacturer: Swecoin AB Dec 8 09:25:46 linux-fceg kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x088C pid 0x2030 Dec 8 09:25:46 linux-fceg kernel: usbcore: registered new interface driver usblp Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver linux-fceg:/var/log # ll /dev/usb* lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 Example: Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { CommPortIdentifier portIdentifier = (CommPortIdentifier) portEnum.nextElement(); System.out.println(portIdentifier.getName() + " - " + getPortTypeName(portIdentifier.getPortType())); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial Virtual LPT port not found... Parallel port /dev/lp0 not foud also. After that i modified source RXTXCommDriver.java, registerScannedPorts if (osName.equals("Linux") { String[] temp = { "lp", // linux printer port "usblp" <====================== add this }; CandidatePortPrefixes = temp; } else if (osName.equals("FreeBSD")) { But /dev/usblp0 not found anyway. After that i modified registerValidPorts if (osName.equals("Solaris") || osName.equals("SunOS")) { checkSolaris(PortName, PortType); } else { if (PortType==CommPortIdentifier.PORT_PARALLEL) <<<< i.e. port type is parallel - don't execute testRead CommPortIdentifier.addPortName( PortName,PortType,this); <<<< else if (testRead(PortName, PortType)) CommPortIdentifier.addPortName( PortName,PortType,this); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial /dev/usblp0 - Parallel /dev/lp0 - Parallel I think, what native testRead incorrectly defines presence of parallel port. I think that presence parallel port can be checked up so: int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) // port is not exist or it is not parallel port else // port is parallel! After that i execute program: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 5000); String str = "12313212312313121231321231231312"; port.getOutputStream().write(str.getBytes()); port.close(); Result: RXTXCommDriver:getCommPort(/dev/usblp0,2) LPRPort:LPRPort(/dev/usblp0) Port /dev/usblp0 in use by another application gnu.io.PortInUseException: Unknown Linux Application linux-fceg:/var/log # lsof | grep /dev/usb I.e. port is not use. Similar result at use /dev/lp0 How i can use parallel ports in my program? PS: Sorry for my english :) From tjarvi at qbang.org Sun Dec 9 00:03:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 00:03:51 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: On Sat, 8 Dec 2007, U. George wrote: >>> But I am not talking about multiple threads reading from the same >>> port. I am dealing with a case in which one thread is reading from the >>> port, and another wants to close the port. >> > So I looked at the RXTX code ( close(), read() ) ( is that what u were > trying to point out ? ) and it seems that a close() may not close. If > there is heavy reading, then maybe close wont happen at all. > > Not sure why read is synchronized. If someone wants to read - > uncoordinated, then that his option! > But the read() and the close() does not appear to have a strong method > of synchronization ( close should set a flag, that would cause any > further I/O requests to throw an exception ). > > On would think that a close() would also prevent any further write() > operations. But it does not. It also does not appear to wait for the > write( b[] ) to complete ( in case the array has to be written out in > chunks bec the kernel buffer is full. ) > Hi George, The code may not look conventional because I wasnt looking at other code at the time. It does do close to what you expect. The code got there the hard way though. close sets the fd to 0 which should throw exceptions if you try IO. while( IOLocked > 0 ) should delay close while reading and writing are in progress. In write(b[]) the following code can be found (comments added): // throw exception if closed. if ( fd == 0 ) throw new IOException(); // prevent closing while writing. IOLocked++; // Ensure the event thread is not being setup. ie // open() waitForTheNativeCodeSilly(); read() has the same logic (deleting some code for clairity) if ( fd == 0 ) throw new IOException(); IOLocked++; waitForTheNativeCodeSilly(); The close(): (for clairity just the code that we care about here:) while( IOLocked > 0 ) { sleep() } removeEventListener(); nativeClose( this.name ); fd = 0; -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 03:35:47 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 05:35:47 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475BA7C9.6090900@gmail.com> References: <475BA7C9.6090900@gmail.com> Message-ID: <475BC503.7010708@gatworks.com> > > linux-fceg:/var/log # ll /dev/usb* > lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 I suppose this is your first issue i would have expected a /dev/usblp0 ->/dev/lp1 ( since most machines have a /dev/lp0 ) > > result: > /dev/ttyS2 - Serial > /dev/ttyS1 - Serial > /dev/ttyS0 - Serial > Virtual LPT port not found... Parallel port /dev/lp0 not foud also. thats bec lp0 its in /dev/usb ! > > LPRPort:LPRPort(/dev/usblp0) > Port /dev/usblp0 in use by another application > gnu.io.PortInUseException: Unknown Linux Application rxtx code: int fd = open( filename, O_RDWR | O_NONBLOCK ); rxtx appears to want to be able to open the device for reading AND writing. I suspect permission failure. 1) anyway have a symbolic pointer from /dev/usb/usblp0 to /dev/lp0 2) change permissions to be RW for you group or owner. From netbeans at gatworks.com Sun Dec 9 04:44:35 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 06:44:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <475BD523.3000900@gatworks.com> > close sets the fd to 0 which should throw exceptions if you try IO. Setting fd to 0 appears to be the last step in rxtx-close. It should be the first step, as a mutex to prevent any further I/O to the channel. With hyperthreads, quad cpu's, other threads can be simultaneously ( in real time ) executing reads & writes & other things. > > while( IOLocked > 0 ) should delay close while reading and writing are > in progress. Yes, but there is nothing there to prevent any further user I/O. You could have a bunch of threads continue to read & write, and keep IOLock > 0 for some time. Even if it did reach IOLock reached 0, there is still the possibility of some thread upping IOLock inbetween. > > In write(b[]) the following code can be found (comments added): > > // throw exception if closed. > if ( fd == 0 ) throw new IOException(); > // prevent closing while writing. Where is the "prevent further writing while closing" ? > > (for clairity just the code that we care about here:) > > while( IOLocked > 0 ) > { sleep() } this can take a long time to process. And defeats the purpose of a close() at time x. Because at time x+1, any further user requests to that file descriptor should have failed. One also has to ask why is the user program still reading or writing after having the close() called? But that is for the user to figure out. The orig question posed was to have a multi cpu, and 2 java threads. 1 thread was reading, while the other was ( attempting to ) closeing. probably something like this should be done: public close() { synchonize( eis ) { we_are_closing_up = true; while ( IOLock > 0 ) sleep( 100ms ); } native_close(); fd = 0; } we_are_closing_up = false; } public write() { if ( we_are_closing_up ) synchronize( eis ) { ; } if ( fd == 0 ) throw ( ..... IOLock++; ...... this is also not perfect. There is the possibility that a close could happen after the test, and before the IOLock++ From beat.arnet at gmail.com Sun Dec 9 05:44:23 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 09 Dec 2007 07:44:23 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475BE327.9010709@gmail.com> Thanks to all for responding to my original question! From what I hear, we now suspect that some improvements in RXTX might be necessary to make the code 100% thread safe. I would be happy to help, but I fear that I might not quite have the necessary training/skills. Maybe with some guidance I could give it a try. Since there has been no official release since 2.1.7, I am also wondering where I should start in the trunk so that I can be sure that all valid bug fixes that have been submitted sine 2.1.7 are included. However, I would also like to find out if there is something short-term that I can do in my application to avoid dead-locks on dual core machines, before RXTX is fixed. After Daniel's response, I synchronized all RXTXPort accesses, but I have still some crashes being reported from the field, albeit much less (and possibly unrelated?). Should I setup my code such that all accesses to the serial port happen in one unique thread? Would this prevent the problems that are described below? Any further guidance from the group would be appreciated. Regards, Beat U. George wrote: >> close sets the fd to 0 which should throw exceptions if you try IO. >> > Setting fd to 0 appears to be the last step in rxtx-close. It should be > the first step, as a mutex to prevent any further I/O to the channel. > With hyperthreads, quad cpu's, other threads can be simultaneously ( in > real time ) executing reads & writes & other things. > > > >> while( IOLocked > 0 ) should delay close while reading and writing are >> in progress. >> > Yes, but there is nothing there to prevent any further user I/O. You > could have a bunch of threads continue to read & write, and keep IOLock > > 0 for some time. > Even if it did reach IOLock reached 0, there is still the possibility of > some thread upping IOLock inbetween. > >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. >> > Where is the "prevent further writing while closing" ? > >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } >> > this can take a long time to process. And defeats the purpose of a > close() at time x. Because at time x+1, any further user requests to > that file descriptor should have failed. > One also has to ask why is the user program still reading or writing > after having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/6b16e64b/attachment-0004.html From tjarvi at qbang.org Sun Dec 9 11:01:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 11:01:00 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > >> close sets the fd to 0 which should throw exceptions if you try IO. > Setting fd to 0 appears to be the last step in rxtx-close. It should be the > first step, as a mutex to prevent any further I/O to the channel. With > hyperthreads, quad cpu's, other threads can be simultaneously ( in real time > ) executing reads & writes & other things. > > >> >> while( IOLocked > 0 ) should delay close while reading and writing are in >> progress. > Yes, but there is nothing there to prevent any further user I/O. You could > have a bunch of threads continue to read & write, and keep IOLock > 0 for > some time. > Even if it did reach IOLock reached 0, there is still the possibility of some > thread upping IOLock inbetween. >> >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. > Where is the "prevent further writing while closing" ? >> >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } > this can take a long time to process. And defeats the purpose of a close() at > time x. Because at time x+1, any further user requests to that file > descriptor should have failed. > One also has to ask why is the user program still reading or writing after > having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 thread > was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could happen > after the test, and before the IOLock++ > There are two questions in the back of my mind. The first is I'd like to see some form of documentation in the Java API that says this is the right behavior. Anything from file IO to network sockets. The second is that we are dealing with perhaps the slowest reads and writes out there. I'd anticipate some downstream impact (incompatability) with people using the current implementation. At least at first, a change like this should be something people opt into via preferences or other means. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 12:17:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 14:17:15 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C3F3B.9050003@gatworks.com> > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. ?? I'm not sure what behavior your are expecting the JAVA docs to explain? I'd be more interested in the OS docs that will/could explain the interaction of threads and the sequencing of I/O operations amongst active cpu instruction pipelines. > > The second is that we are dealing with perhaps the slowest reads and > writes out there. I'd anticipate some downstream impact > (incompatability) with people using the current implementation. At > least at first, a change like this should be something people opt into > via preferences or other means. u mean there are folks that continue to read & write even though they also issued a (premature) close ? I am not aware of any OS that behaves like that. Or allows that. Yes, but if you will notice, the the speed of USB devices, that are made to behave like serial, or parallel devices, are very-very fast. A 500ms sleep is forever on some USB devices. BTW: Since JAVA source went public, sorta, did java publish the commapi source? BTW#2:Your mail to 'Rxtx' with the subject If not DEBUGing, remove useless calls to report() et al Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 46243 bytes with a limit of 40 KB From netbeans at gatworks.com Sun Dec 9 13:00:09 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 15:00:09 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C4949.5060109@gatworks.com> > > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. from Class CommPort: After a communications port has been identified and opened it can be configured with the methods in the low-level classes like SerialPort and ParallelPort. Then an IO stream can be opend for reading and writing data. Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown. From dwippermann at gmx.net Sun Dec 9 13:36:28 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:36:28 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: Hi all, > If you can you should assign the responsibility of closing the port > to the one > handling the port. The other thread should simply be telling the > handling thread > that it should close the port. Threads are like people, in that if > you give them > conflicting instructions all hell breaks loose. For example of what > I think you > should do: > yes, that you be the common way if I had full control over the thread. But the thread is implemented and started by RXTX, I only get event through my listener. How should the listener be able to close the port if no event is triggered? Can I wake up the RXTX thread to send a dummy event to trigger the close from inside the listener? Daniel From dwippermann at gmx.net Sun Dec 9 13:55:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:55:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: And hi once more, > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ Thats the reason why I encapsulated all access in synchronized blocks using one mutex. You simply have no problem with "after ... , but before..." anymore :) One other problem I see is the use of the ++/-- operators on a variable that can be accessed by mutliple threads in parallel. I'll run a short test tomorrow on my office machine, but I assume that its read-modify-write behaviour might bring up a collision like: IOLocked = 100, both thread are running in different CPUs, but due to timing arrive at the "IOLocked--" nearly simultaneously CPU 1: reads variable to register => register = 100 CPU 2: doing something else -- CPU 1: decrements register => register = 99 CPU 2: reads variable to register => register = 100 -- CPU 1: writes register to variable => variable = 99 CPU 2: decrements register => register = 99 -- CPU 1: doing something else CPU 2: writes register to variable => variable = 99 It should have decremented twice, but it didn't... Thats a common situtation where locking is needed: modify the same variable from different threads without synchonization is hell :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/4bd9d474/attachment-0003.html From netbeans at gatworks.com Thu Dec 6 04:14:53 2007 From: netbeans at gatworks.com (U. George) Date: Thu, 06 Dec 2007 06:14:53 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al Message-ID: <4757D9AD.2080305@gatworks.com> For the most part the report() calls from everywhere is usefull in debugging whats happening within rxtx. BUT if you are not debugging, then it is just wasted CPU cycles. That also includes the sprintf's sprinkled here and there. I placed the DEBUG code ( SerialImp.c ) under the #ifdef DEBUG . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071206/92c448eb/attachment-0003.pl From tjarvi at qbang.org Sun Dec 9 19:15:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:15:44 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <4757D9AD.2080305@gatworks.com> References: <4757D9AD.2080305@gatworks.com> Message-ID: This looks OK to me George. Just two issues. make_message is probably copyrighted by the Free Software Foundation. It is probably easier to recode it than deal with the minor potential issues. The only other minor issue is that commenting out code isn't really better than deleting it in the long run. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 19:35:41 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 21:35:41 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> Message-ID: <475CA5FD.6050801@gatworks.com> Trent Jarvi wrote: > > This looks OK to me George. Just two issues. > > make_message is probably copyrighted by the Free Software Foundation. > It is probably easier to recode it than deal with the minor potential > issues. code u refer to is not used. I'm not too sure if "all" cc/libs can handle the particular var-args scheme. So if blows up, then that becomes an issue, but not harmfull for anybody's run. I did want to use it to do: REPORT("FIONREAD failed with error %s\n", strerror( errno )); or more recently REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); Since u PORT this to other machines, its not clear if var-args works everywhere the same way. u got any notion? > > The only other minor issue is that commenting out code isn't really > better than deleting it in the long run. > Sorta, sorta not. For short run ( in the heading of small changes ) it looks just like all the other items (historically) commented out, but not yet removed :) More things to clean up for the long run i guess. From tjarvi at qbang.org Sun Dec 9 19:47:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:47:37 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <475CA5FD.6050801@gatworks.com> References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> >> This looks OK to me George. Just two issues. >> >> make_message is probably copyrighted by the Free Software Foundation. It >> is probably easier to recode it than deal with the minor potential issues. > code u refer to is not used. I'm not too sure if "all" cc/libs can handle the > particular var-args scheme. So if blows up, then that becomes an issue, but > not harmfull for anybody's run. > > I did want to use it to do: > REPORT("FIONREAD failed with error %s\n", strerror( errno )); > > or more recently > > REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); > > Since u PORT this to other machines, its not clear if var-args works > everywhere the same way. u got any notion? > >> >> The only other minor issue is that commenting out code isn't really better >> than deleting it in the long run. >> > Sorta, sorta not. For short run ( in the heading of small changes ) it looks > just like all the other items (historically) commented out, but not yet > removed :) More things to clean up for the long run i guess. > So far as I know, var-args works fine on the other platforms. See ioctl in termios.c (w32) for instance. I would rather link to make_message or implement a work alike. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 20:49:44 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 22:49:44 -0500 Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: References: Message-ID: <475CB758.6000508@gatworks.com> rxtx-bounces at qbang.org wrote: > Your mail to 'Rxtx' with the subject > > Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al > > Is being held until the list moderator can review it for approval. I suppose this limitation was a recent change? :/ From tjarvi at qbang.org Sun Dec 9 20:55:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 20:55:33 -0700 (MST) Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: <475CB758.6000508@gatworks.com> References: <475CB758.6000508@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > > rxtx-bounces at qbang.org wrote: >> Your mail to 'Rxtx' with the subject >> >> Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al >> >> Is being held until the list moderator can review it for approval. > > > I suppose this limitation was a recent change? :/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > No. It is just a size limititation. I have upped it in the past. You might consider sending it as a .gz/.zip. Many people end up with full mailboxes and then bounce. The size limitation is 3 years old. The reason I don't get to the deffered email very often is it gets about 1k spams a week. At least we keep the spam out of everyones email box. If you like, I can fish out your email. I'd suggest zipping it though. There are ~500 people on the list but most just want to follow along. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 21:07:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 23:07:15 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: <475CBB73.9080805@gatworks.com> > So far as I know, var-args works fine on the other platforms. See ioctl > in termios.c (w32) for instance. > dont have a win32 development system. At least not a recent one. And not installed anywhere :}} > I would rather link to make_message or implement a work alike. Its not a problem. looks almost like the jprint( ... ). -------------- next part -------------- A non-text attachment was scrubbed... Name: IfDef_patch.gz Type: application/x-gzip Size: 10381 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/5a6ec2c1/attachment-0003.gz From vorobyev.a at gmail.com Mon Dec 10 00:41:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 10:41:32 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475CEDAC.9090907@gmail.com> >2) change permissions to be RW for you group or owner. Thanks, it is my stupid mistake. But usb printer not work anyway. Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; ========================================== test program in c++: void ParallelPort::test(){ int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) return ; printf("status: 0x%02x\n",status); printf("Busy (~status & LP_PBUSY) : %x\n", (~status & LP_PBUSY)); printf("Error (~status & LP_PERRORP): %x\n", (~status & LP_PERRORP)); printf("Select (status & LP_PSELECD) : %x\n", (status & LP_PSELECD)); printf("Paper out (status & LP_POUTPA) : %x\n", (status & LP_POUTPA)); } result: status: 0x18 Busy (~status & LP_PBUSY) : 80 Error (~status & LP_PERRORP): 0 Select (status & LP_PSELECD) : 10 Paper out (status & LP_POUTPA) : 0 ParallelPort port("/dev/usblp0"); port.open(); port.write("Hello world"); port.write(0x1e); // cut port.close(); Result: Device print data and cut paper. ========================================== test program in java: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 50000); System.out.println("paper out: "+ port.isPaperOut()); System.out.println("buzy: "+ port.isPrinterBusy()); System.out.println("error: "+ port.isPrinterError()); System.out.println("select: "+ port.isPrinterSelected()); System.out.println("timeout: "+ port.isPrinterTimedOut()); result: paper out: true buzy: false error: false select: false timeout: false From netbeans at gatworks.com Sun Dec 9 22:04:46 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 00:04:46 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475CEDAC.9090907@gmail.com> References: <475CEDAC.9090907@gmail.com> Message-ID: <475CC8EE.9040205@gatworks.com> Alexander Vorobyev wrote: >> 2) change permissions to be RW for you group or owner. > Thanks, it is my stupid mistake. > > But usb printer not work anyway. > Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; I suppose the USB/LP driver may not be sophisticated enough to provide that information, presuming that information is at all relevant to the device itself ( like a parallel port Zip Drive ). From vorobyev.a at gmail.com Mon Dec 10 01:46:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 11:46:32 +0300 Subject: [Rxtx] One more question about usb->lpt Message-ID: <475CFCE8.3080807@gmail.com> Good day I wrote about the arisen problems at work with the device/dev/usb/lp0. At use c ++ work with the given device is made easily enough. Example void Usb2Lpt::open(){ handle = ::open(this->device.c_str(),O_RDWR|O_NOCTTY|O_NDELAY); if (handle<0) throw FileNotOpenException(strerror(errno)); } void Usb2Lpt::close(){ ::close(handle); handle = -1; } void Usb2Lpt::waitForRead(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, &rfds, NULL, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } void Usb2Lpt::waitForWrite(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, NULL, &rfds, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } unsigned char* Usb2Lpt::read(uint size){ .... r = ::read(handle,buf,len); ... return buf; } int Usb2Lpt::write(char data){ int w; waitForWrite(); w = ::write(handle,&data,sizeof(data)); if (w==-1){ if (errno==EAGAIN) return 0; else throw IOException(strerror(errno); } return w; } I.e. it is work as write/read + blocking/nonblocking mode; It is how much easy to make support of such driver in library rxtx? From zhouzhao58 at 163.com Mon Dec 10 05:13:14 2007 From: zhouzhao58 at 163.com (=?GBK?B?1tzuyA==?=) Date: Mon, 10 Dec 2007 20:13:14 +0800 (CST) Subject: [Rxtx] Help me ,please Message-ID: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> I used a common-user in the MAC OS 10.5. When i used rxtx 2.1.7 to open the serial port on the MAC OS 10.5.the rxtx has a error. how can I do ? thanks description: error testing lock file creation error details:permission deniedcheck_lock_status:no perminssion to create lock file. please see: how can I use lock files with rxtx ? in install -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/0ebc8026/attachment-0003.html From dwippermann at gmx.net Mon Dec 10 05:29:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 13:29:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Hi again, > One other problem I see is the use of the ++/-- operators on a > variable that can be accessed by mutliple threads in parallel. I'll > run a short test tomorrow on my office machine, but I assume that > its read-modify-write behaviour might bring up a collision like: > > IOLocked = 100, both thread are running in different CPUs, but due > to timing arrive at the "IOLocked--" nearly simultaneously > > CPU 1: reads variable to register => register = 100 > CPU 2: doing something else > -- > CPU 1: decrements register => register = 99 > CPU 2: reads variable to register => register = 100 > -- > CPU 1: writes register to variable => variable = 99 > CPU 2: decrements register => register = 99 > -- > CPU 1: doing something else > CPU 2: writes register to variable => variable = 99 > > It should have decremented twice, but it didn't... Thats a common > situtation where locking is needed: modify the same variable from > different threads without synchonization is hell :) Small sample app: (((snip))) public class Main { static Object mutex; static int counter; public static void concurrencyTest(final boolean useMutex) { Runnable r = new Runnable() { public void run() { synchronized(mutex) { try { mutex.wait(); } catch (Exception ex) { ex.printStackTrace(); } } for (int i = 0; i < 1000000; i++) { if (useMutex) { synchronized (mutex) { counter++; } } else { counter++; } } } }; try { counter = 0; mutex = new Object(); Thread t1 = new Thread(r); Thread t2 = new Thread(r); // start the two threads, they will wait for the mutex to be signaled t1.start(); t2.start(); // just a little sleep before the work Thread.sleep(100); synchronized (mutex) { // signal the two threads to start working mutex.notifyAll(); } t1.join(); t2.join(); System.out.println("useMutex = " + useMutex + " => counter = " + counter); } catch (Exception ex) { ex.printStackTrace(); } } public static void main(String[] args) { concurrencyTest(true); concurrencyTest(false); } } (((snip))) The program starts two threads. Each thread should increment a counter 1 million times, hence you expect a result of 2 million. Haven't tested it on a single-core machine, but on my multi-core office machine I get: useMutex = true => counter = 2000000 useMutex = false => counter = 1221835 The second result is fluctuating heavily. By that example I want to demonstrate that the use of "IOLocked++" for locking purposes is by far not thread-safe. And if you have heavy trafiic over the serial port (as I have, up to 2,8 MB of data to transceive at 115kbps), the chance of synchronization issues is reasonable. The only possibility I have to counter this at the moment is to synchronize all function calls to RXTX, especially close(), getInputStream(), read() as well as getOutputStream() and write(). It cannot be taken as a general advise to solve this problem, because synchronization has to fit into thr rest of your app. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/99aca116/attachment-0003.html From netbeans at gatworks.com Mon Dec 10 06:59:29 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 08:59:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D4641.7050001@gatworks.com> > By that example I want to demonstrate that the use of "IOLocked++" for > locking purposes is by far not thread-safe. And if you have heavy > trafiic over the serial port (as I have, up to 2,8 MB of data to > transceive at 115kbps), the chance of synchronization issues is reasonable. Synchronization of read/writes should be handled by the user. There is nothing in rxtx that will disturb the synchronization, as it is not an rxtx function. If a user wants to have 3 threads writing to that device, its up to the user to coordinate the proper sequencing of writes. The synchronize reads in SerialImp/read() appear to be a violation of the abstract class InputStream. If you want 3 threads simultaneously reading from that device, then thats up to the users application to determine the sequence for access. The IOLocked is a flag to indicate that a read/write I/O operation is in progress. it does not lockout the other from happening simultaneously. The synchronize read() does prevent simultaneous reads from multiple threads. The IOLocked indicator does prevent the close() from starting up, as close() waits for the IOLock value to become 0. The presumption is that the application's reads/writes will cease because the application has issued a close(). You wouldnt issue any further I/O after the close - would you? From dwippermann at gmx.net Mon Dec 10 07:53:03 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 15:53:03 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi all, > The IOLocked is a flag to indicate that a read/write I/O operation > is in > progress. it does not lockout the other from happening simultaneously. > The synchronize read() does prevent simultaneous reads from multiple > threads. > The IOLocked indicator does prevent the close() from starting up, as > close() waits for the IOLock value to become 0. The presumption is > that > the application's reads/writes will cease because the application has > issued a close(). You wouldnt issue any further I/O after the close - > would you? You are completely right, I never meant to imply something different. The IOLocked shall not lock concurrent reads or concurrents writes away, but be a signal for the close method that some read or write is still underway and it has to wait for them to finish. But the original question was, why the IOLocked variable has a value ! = 0 ALTHOUGH all read and write activities have ceased quite a while ago? And there were only two threads involved: on one side the thread that called open() and write() and on the other side the RXTX monitor thread that calling read(). No multiple reads or writes! Only a parallel write while reading. But that cannot be forbidden since we talk about an USART. Or am I wrong? Is there a problem to to have one read() and one write() run simulatenously? If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/db7e990f/attachment-0002.html From netbeans at gatworks.com Mon Dec 10 10:17:26 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 12:17:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D74A6.4000209@gatworks.com> > If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). i suppose u mean that the IOLocked++, and the IOLocked-- has to be accomplished atomically ? I suppose besides meaning that you would also like that? :} From dwippermann at gmx.net Mon Dec 10 10:22:40 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:22:40 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi everone, > Hi all, >> The IOLocked is a flag to indicate that a read/write I/O operation >> is in >> progress. it does not lockout the other from happening >> simultaneously. >> The synchronize read() does prevent simultaneous reads from multiple >> threads. >> The IOLocked indicator does prevent the close() from starting up, as >> close() waits for the IOLock value to become 0. The presumption is >> that >> the application's reads/writes will cease because the application has >> issued a close(). You wouldnt issue any further I/O after the close - >> would you? > You are completely right, I never meant to imply something > different. The IOLocked shall not lock concurrent reads or > concurrents writes away, but be a signal for the close method that > some read or write is still underway and it has to wait for them to > finish. > But the original question was, why the IOLocked variable has a > value != 0 ALTHOUGH all read and write activities have ceased quite > a while ago? And there were only two threads involved: on one side > the thread that called open() and write() and on the other side the > RXTX monitor thread that calling read(). No multiple reads or > writes! Only a parallel write while reading. But that cannot be > forbidden since we talk about an USART. Or am I wrong? Is there a > problem to to have one read() and one write() run simulatenously? > If that case is an allowed one, IOLocked has to be synchronized > because it is altered in read() and write(). I've prepared a patch to RXTXPort.java to help me outline my point of view in this discussion. It's attached to this posting. In general, three things have been done: 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be passed as a parameter to the synchronized statement. 2) Every "IOLocked++" is encapsulated by that said synchronized block 3) In some methods there were multiple "IOLocked--". Those have all been substituted by a one synchronized "IOLocked--" which is processed in a "finally" statement that handles all exceptions from right after "IOLocked++" till the end of the method. So every occurence or variation of the sequence: > IOLocked++; > waitForTheNativeCodeSilly(); > try { > // something method specific here > } catch (IOException ex) { > IOLocked--; > throw ex; > } > IOLocked--; has been replaced by: > synchronized (IOLockedMutex) { > IOLocked++; > } > try { > waitForTheNativeCodeSilly(); > // something method specific here > } finally { > synchronized (IOLockedMutex) { > IOLocked--; > } > } In my opinion that chance has no impact on the surrounding application. It wont block away one function call if another one is running, it only ensures, that only one thread alters the IOLocked variable at any given time. So you could have one polling read() and one write() action in parallel without interference. In the hope, that I haven't abused your patience too much :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RXTXPort_IOLockedMutex.diff Type: application/octet-stream Size: 6297 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0002.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0005.html From dwippermann at gmx.net Mon Dec 10 10:44:17 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:44:17 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Hi! > i suppose u mean that the IOLocked++, and the IOLocked-- has to be > accomplished atomically ? > > I suppose besides meaning that you would also like that? :} Yes, indeed... I was lacking the word "atomically", but at least you were able to follow my remaining semi-english explanation :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/5f88033d/attachment-0001.html From netbeans at gatworks.com Mon Dec 10 14:03:38 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 16:03:38 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DA9AA.90106@gatworks.com> According to this (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): > A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking. It appears that "volatile" makes concurrent updates atomic. Its not intuitive. So is it true ? Daniel Wippermann wrote: > Hi! > >> i suppose u mean that the IOLocked++, and the IOLocked-- has to be >> accomplished atomically ? >> >> I suppose besides meaning that you would also like that? :} > Yes, indeed... I was lacking the word "atomically", but at least you > were able to follow my remaining semi-english explanation :) > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dwippermann at gmx.net Mon Dec 10 14:33:02 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 22:33:02 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: Hi, > According to this > (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html > ): > > A write to a volatile field happens-before every subsequent read > of that same field. Writes and reads of volatile fields have similar > memory consistency effects as entering and exiting monitors, but do > not entail mutual exclusion locking. > > It appears that "volatile" makes concurrent updates atomic. Its not > intuitive. So is it true ? > I tried the volatile declaration on my small ConcurrencyTest app. It has no effect, the unsynchronized version still misses a vast amount of increments. I think that the read-modify-write behaviour of "++" and "--" is not covered by the "happens-before" clause of the volatile declaration. It only ensures, that the corresponding read and write operations are not interrupted, the time in between these operations is not covered. Although it sounded promising on the first look... I can't imagine a different working approach to get IOLocked thread- safe at the moment. But perhaps I'm stuck and just have to think about it another night or two... Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/d13a0db5/attachment-0001.html From netbeans at gatworks.com Mon Dec 10 15:32:42 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 17:32:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DBE8A.8050408@gatworks.com> I suspect that what they said is not exact. My impression, at one time, was that the volatile object could not be optimized into not writing to memory. Oh well. Have you tried java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? from jdk1.5 and beyond? these set of utilities have an interesting way of 'atomically' incrementing the variable. I'd be curious if your test would also fail using these utilities. Daniel Wippermann wrote: > Hi, > >> According to this >> (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): >> >/ A write to a volatile field happens-before every subsequent read of >> that same field. Writes and reads of volatile fields have similar >> memory consistency effects as entering and exiting monitors, but do >> not entail mutual exclusion locking. / It appears that "volatile" >> makes concurrent updates atomic. Its not intuitive. So is it true ? > > > I tried the volatile declaration on my small ConcurrencyTest app. It has > no effect, the unsynchronized version still misses a vast amount of > increments. > > I think that the read-modify-write behaviour of "++" and "--" is not > covered by the "happens-before" clause of the volatile declaration. It > only ensures, that the corresponding read and write operations are not > interrupted, the time in between these operations is not covered. > Although it sounded promising on the first look... > > I can't imagine a different working approach to get IOLocked thread-safe > at the moment. But perhaps I'm stuck and just have to think about it > another night or two... > > Daniel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com.cn Mon Dec 10 19:22:23 2007 From: zhanglong at adventnet.com.cn (zl) Date: Tue, 11 Dec 2007 10:22:23 +0800 Subject: [Rxtx] Homestay 2008 Beijing Olympic Message-ID: <475DF45F.5030702@adventnet.com.cn> Do you want to come to Beijing for 2008 Olympic? Please choose homestay for your accommodation and select my home. Introduction: The whole apartment is furnished in traditional Chinese Style. All furniture is brand new. There are two bedrooms, a modern kitchen, a living room, one bathrooms and one storageroom. It has all the gadgets and amenities including ADSL internet connection, on-demand cable, washer, fridge, microwave, a 25 inch television set, home security system.And community body guard is also included. 24 hours hot water services, local banking facilities,air conditioners are available. Everything is comfortable for living, also supermarket(Carrefour is 5 minuters), park, school, restaurants, entertainment places is surrounding. It's about 10 minutes' drive to the National Stadium (the Bird Nest), and no longer than 5 minutes' walk to the Olympics Forest Park. The subway line 13 and 5 's station of Lishuiqiao is 5-10 minutes' walking distance. For more detail and pictures,Please look at: http://picasaweb.google.com/zlong6688/HomestayBeijing2008 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249599243132994 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249629307904114 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096615126729827426 Contact me: E-mail: zhanglong at adventnet.com.cn Mobile: 13241969320 MSN:zlong6666 at hotmail.com PS: Please help me tell this message to your friends. And you can post this message with no limit. (End) ------------------------------------------------- From dwippermann at gmx.net Mon Dec 10 22:02:59 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 06:02:59 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Hi, > I suspect that what they said is not exact. My impression, at one > time, > was that the volatile object could not be optimized into not writing > to > memory. Oh well. > > Have you tried > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? > from jdk1.5 and beyond? > > these set of utilities have an interesting way of 'atomically' > incrementing the variable. I'd be curious if your test would also fail > using these utilities. thanks for that hint, an interesting package :) This class works as expected and is way faster (at least on my machine) that synchronizing the increment manually. The only drawback - as you mentioned before - is that it requires Java5 to run... And as far as I understand, RXTX targets 1.3 and later JREs... But an eyecatcher indeed, thanks again. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/376692e5/attachment-0001.html From netbeans at gatworks.com Tue Dec 11 05:28:29 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 07:28:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Message-ID: <475E826D.40609@gatworks.com> u didnt catch it all. although introduced in 1.5, those same folks ( not sun ) who made that stuff public domain, also created a 1.4 version, and a 1.3 version. Those backward compatable routines are 'synchronize'd, so should run no better that what rxtx is currently doing. BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx synchronize directives be completely removed from reads and writes ( as well as the removal of IOLocked et al ) ? Daniel Wippermann wrote: > Hi, > >> I suspect that what they said is not exact. My impression, at one time, >> was that the volatile object could not be optimized into not writing to >> memory. Oh well. >> >> Have you tried >> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? >> from jdk1.5 and beyond? >> >> these set of utilities have an interesting way of 'atomically' >> incrementing the variable. I'd be curious if your test would also fail >> using these utilities. > > thanks for that hint, an interesting package :) > > This class works as expected and is way faster (at least on my machine) > that synchronizing the increment manually. > > The only drawback - as you mentioned before - is that it requires Java5 > to run... And as far as I understand, RXTX targets 1.3 and later JREs... > > But an eyecatcher indeed, thanks again. > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Tue Dec 11 08:48:41 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 11 Dec 2007 10:48:41 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475E826D.40609@gatworks.com> References: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <475E826D.40609@gatworks.com> Message-ID: I confirmed Daniel's theory by running his example on both a dual-core and single-core machine. Both counter results are identical on a single core machine, and differ on dual cores. I then tried the synchronized and concurrent.atomic approach and noticed that they both make RXTXPort unbearably slow. Thanks for all your help! Beat On Dec 11, 2007 7:28 AM, U. George wrote: > u didnt catch it all. although introduced in 1.5, those same folks ( not > sun ) who made that stuff public domain, also created a 1.4 version, and > a 1.3 version. Those backward compatable routines are 'synchronize'd, so > should run no better that what rxtx is currently doing. > > > BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx > synchronize directives be completely removed from reads and writes ( as > well as the removal of IOLocked et al ) ? > > Daniel Wippermann wrote: > > Hi, > > > >> I suspect that what they said is not exact. My impression, at one time, > >> was that the volatile object could not be optimized into not writing to > >> memory. Oh well. > >> > >> Have you tried > >> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? > >> from jdk1.5 and beyond? > >> > >> these set of utilities have an interesting way of 'atomically' > >> incrementing the variable. I'd be curious if your test would also fail > >> using these utilities. > > > > thanks for that hint, an interesting package :) > > > > This class works as expected and is way faster (at least on my machine) > > that synchronizing the increment manually. > > > > The only drawback - as you mentioned before - is that it requires Java5 > > to run... And as far as I understand, RXTX targets 1.3 and later JREs... > > > > But an eyecatcher indeed, thanks again. > > > > Daniel > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/356ff730/attachment-0001.html From dwippermann at gmx.net Tue Dec 11 08:50:07 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 16:50:07 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Message-ID: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Hi all, > Those backward compatable routines are 'synchronize'd, so > should run no better that what rxtx is currently doing. Why do you think so? All write() methods in the SerialOutputStream class are not synchronized at all at the moment. And the "synchronized" read() methods only forbid to call more than one of them at any given time because they lock the SerialInputStream object they are living in. But they have no locking influence on a concurrent write() and its altering of IOLocked. So rxtx would do much better than what it is currently doing. > BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx > synchronize directives be completely removed from reads and writes > ( as > well as the removal of IOLocked et al ) ? That's not my decision to make, it's more a political question whether the library takes care of it or the end user developer. You can of course remove it all and let the user take care of it... If you ask me personally: I believe it makes perfect sense to do it in the library. The speed impact is marginal. But it touches the integrity of the library state (since IOLocked cannot be influenced directly from outside). If you cannot close the port because an internal variable's content is damaged, that is nothing to be handled by the end user dev. From my point of view it's the library's responsibility. But I'm tired of "defending" my position here. If you think, it is ok how it is done at the moment: fine, let's end that discussion here. That's the advantage of open source and an open mind: just branch, patch and continue :) On a small side note I'd like to thank Trent, Martin and all the other contributors of this project. It's damn good lib and saved me a lot of time in the past. Keep up the good work, guys! Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/78331b1d/attachment.html From Steffen.DETTMER at ingenico.com Tue Dec 11 09:26:30 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 11 Dec 2007 17:26:30 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <20071211162630.GI2253@elberon.bln.de.ingenico.com> * Daniel Wippermann wrote on Tue, Dec 11, 2007 at 16:50 +0100: > > BTW: wouldnt all run a whole lot better ( faster anyway ) if > > the rxtx synchronize directives be completely removed from > > reads and writes ( as well as the removal of IOLocked et al) ? > > If you ask me personally: I believe it makes perfect sense to > do it in the library. The speed impact is marginal. But it > touches the integrity of the library state (since IOLocked > cannot be influenced directly from outside). I agree. The alternative would be to require that each using application needs to serialise any call to lib functions. In Java usually multiple threads are very common, so I think its likely that all applications would need to add some locking around. I'm afraid it would be uncomfortable, difficult and `risky' to use then (and if not locked correctly, strange behavior could happen later on, after tests, and so on... personally I really hate such problems because they are hard to find, so best is to avoid them I think :)). So I think, having (or keeping, with some extensions / fixes) this `threadsafety' as a lib feature keeps rxtx easily usable and everyone would benefit :) > On a small side note I'd like to thank Trent, Martin and all > the other contributors of this project. It's damn good lib and > saved me a lot of time in the past. Keep up the good work, > guys! well said, again I agree! :) Yes, thanks a lot guys!! oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Tue Dec 11 09:40:45 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 17:40:45 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net><6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net><695CE8C6-D794-464A-9550-150C1501A09F@gmx.net><475E826D.40609@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B0F@ism-mail03.corp.ad.wrs.com> Hi all, I haven't had time to follow this thread in too much detail, but Daniel's argument as well as his patch make perfectly sense to me. The modifications he made seem to be required to ensure data integrity in a multi-threaded enviroment, and his methods (add an additional mutex, use try...finally) seem perfectly right to me: ensuring data integrity, without changing any other semantics of the existing implementation (especially read/write concurrency on a higher level). I also agree that data integrity needs to be maintained at the library level, and not offloaded to the client by not using synchronized at all. I can't understand why these modifications should make RXTXPort a lot slower. On modern JVM's, the "synchronized" statement is processed real fast. Beat can you give more background about your measurements? Daniel: thanks for your contributions and your perseverance. Please don't give up and create your own branch of RXTX. We need guys like you in our Open Source Community :-) Thanks Martin ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, December 11, 2007 4:49 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem I confirmed Daniel's theory by running his example on both a dual-core and single-core machine. Both counter results are identical on a single core machine, and differ on dual cores. I then tried the synchronized and concurrent.atomic approach and noticed that they both make RXTXPort unbearably slow. Thanks for all your help! Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/6333f1fa/attachment.html From netbeans at gatworks.com Tue Dec 11 09:44:24 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 11:44:24 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <475EBE68.8030606@gatworks.com> Daniel Wippermann wrote: > Hi all, > >> Those backward compatable routines are 'synchronize'd, so >> should run no better that what rxtx is currently doing. > > Why do you think so? All write() methods in the SerialOutputStream class > are not synchronized at all at the moment. And the "synchronized" read() > methods only forbid to call more than one of them at any given time > because they lock the SerialInputStream object they are living in. But > they have no locking influence on a concurrent write() and its altering > of IOLocked. So rxtx would do much better than what it is currently doing. Because, if you were to use the (AtomicInteger) IOLocked.getAndIncrement(); u would get a hotspot/native operation in JDK1.5 and JDK1.6, but with jdk1.3 & 1.4, with the backward compatible routines, you would get the synchronise'd routine for getAndIncrement. the JDK1.3 backward routine would be just as good as your suggested code: synchronize( oIOLocked ) { IOLocked++; } > >> BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx >> synchronize directives be completely removed from reads and writes ( as >> well as the removal of IOLocked et al ) ? > > That's not my decision to make, it's more a political question whether > the library takes care of it or the end user developer. You can of > course remove it all and let the user take care of it... For some its what the docs say ( or suggest anyway ) > > If you ask me personally: I believe it makes perfect sense to do it in > the library. The speed impact is marginal. But it touches the integrity > of the library state (since IOLocked cannot be influenced directly from > outside). If you cannot close the port because an internal variable's > content is damaged, that is nothing to be handled by the end user dev. > From my point of view it's the library's responsibility. The point being is that IOLocked is not necessary for the integrity or the state of the library. Nor is the ( forced upon you ) synchronized reads. thats an IMHO. > > But I'm tired of "defending" my position here. If you think, it is ok > how it is done at the moment: I'm not sure what u mean? For my USB/serial io device, rxtx spins & spins. So its not OK at the moment. When I remove (unplug) the serial device, it also spins and spins. Also not an OK situation. And I really hate it when a close() refuses to do so! fine, let's end that discussion here. I thought we were addressing bugs. From Martin.Oberhuber at windriver.com Tue Dec 11 09:48:38 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 17:48:38 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475C3F3B.9050003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> U.George wrote: BTW: Since JAVA source went public, sorta, did java publish the commapi source? Sun is publishing the OpenJDK under GPL 2 (with "classpath exception" for SOME files only, see the last paragraph of following link): http://openjdk.java.net/legal/gplv2+ce.html whereas RXTX is under (modified) LGPL. Please DONT go copy&paste GPL'd Sun code into LGPL'd RXTX. That would be a BIG problem at least for some companies using RXTX. GPL is viral in that it might force companies open-source their proprietary stuff if they link against a GPL'd lib! LGPL is not that viral, at least not when linking dynamically. We'd really have a problem when RXTX is infected with GPL'd code fragments. Therefore, please DONT even try finding the GPL'd Sun code, read it or reference it otherwise. It's really a big threat. Really. Thanks, Martin From Martin.Oberhuber at windriver.com Tue Dec 11 10:04:20 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:04:20 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BE327.9010709@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> <475BE327.9010709@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B23@ism-mail03.corp.ad.wrs.com> Hi Beat, > Should I setup my code such that all accesses > to the serial port happen in one unique thread? > Would this prevent the problems that are described? Yes, I think that accessing your RXTXPort from a single thread should work around all the issues discussed here. One option for doing so might be if you create a "frontend" for your RXTXPort like a PipedStream that runs in a single thread but accepts input from multiple threads. Such code could be based on a BoundedBufferWithStateTracking See http://gee.cs.oswego.edu/dl/cpj/allcode.java and http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.core/terminal/or g.eclipse.tm.terminal/src/org/eclipse/tm/internal/terminal/textcanvas/Pi pedInputStream.java?root=DSDP_Project&view=markup Cheers, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/41f74564/attachment.html From Martin.Oberhuber at windriver.com Tue Dec 11 10:05:56 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:05:56 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B26@ism-mail03.corp.ad.wrs.com> U.George wrote: > close should set a flag, that would cause any further > I/O requests to throw an exception ). +1, I fully agree. Cheers, Martin From Martin.Oberhuber at windriver.com Tue Dec 11 10:09:06 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:09:06 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47598A99.2010601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47598A99.2010601@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B2C@ism-mail03.corp.ad.wrs.com> > > try { > > getSerialPort().removeEventListener(); > > Thread.sleep(50); //allow a little time for RXTX Native to catch > > up > > whats there to catch up? > what that a patch for user code? or for RXTX ? This was a "hack workaround" in our user code that helped fixing an issue we had. I don't know why it works, but it works. With all the discusssions we've had so far, it should be possible to make close() thread-safe such that this workaround is not needed any more. Cheers Martin From netbeans at gatworks.com Tue Dec 11 10:11:04 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 12:11:04 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <20071211162630.GI2253@elberon.bln.de.ingenico.com> References: <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> <20071211162630.GI2253@elberon.bln.de.ingenico.com> Message-ID: <475EC4A8.6050204@gatworks.com> > So I think, having (or keeping, with some extensions / fixes) > this `threadsafety' as a lib feature keeps rxtx easily usable and > everyone would benefit :) Being synchronize'd does not guarantee the correct ordering of I/O operations. When the synchronized routine completes, all waiters are woken at the same time, and all have an opportunity ( but not all equal ) to obtain the sync'd routine. That type of coordination is beyond a library. From dwippermann at gmx.net Tue Dec 11 11:08:53 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 19:08:53 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <06C5F84B-E3F7-42E5-8248-42C03251F511@gmx.net> Hi all, > >> Those backward compatable routines are 'synchronize'd, so > >> should run no better that what rxtx is currently doing. > > > > Why do you think so? All write() methods in the SerialOutputStream > class > > are not synchronized at all at the moment. And the "synchronized" > read() > > methods only forbid to call more than one of them at any given time > > because they lock the SerialInputStream object they are living in. > But > > they have no locking influence on a concurrent write() and its > altering > > of IOLocked. So rxtx would do much better than what it is > currently doing. > Because, if you were to use the (AtomicInteger) > IOLocked.getAndIncrement(); u would get a hotspot/native operation in > JDK1.5 and JDK1.6, but with jdk1.3 & 1.4, with the backward compatible > routines, you would get the synchronise'd routine for getAndIncrement. > the JDK1.3 backward routine would be just as good as your suggested > code: > synchronize( oIOLocked ) { > IOLocked++; > } Oh, my fault. When I read "what rxtx is currently doing" I did not include my patch submission, since I do not count it as an official part of RXTX :) But yes, then you are right, it would make no difference in version prior to JDK5 and speed up things for all other versions. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/25160f31/attachment.html From netbeans at gatworks.com Tue Dec 11 11:36:42 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 13:36:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> Message-ID: <475ED8BA.6040403@gatworks.com> The Commapi was not published. Suns philosophy was to have people learn their methods and madness. Sun also believed that you will forget the particular code in a few weeks, rather than the usual 2 years. So it was written. But you seem to forget that in order to replicate the behavior of that code, u need to look at the DOCS. And when that is not specific enough, then there has to be other ways to get that information. For instance the InputStream.read() is not DOC'd as synchronized. Nor is FileInputStream.read synchronized ( as per inspection of the JDK source ). If I further investigate, probably none of the InputStream derivatives are synchronized. Now that I have stated this, does your compliance with DOC's, in the removal of the synchronize, also mean that you adopted another coding license? And if the commapi code were to be published, and did not have the synchronized read ( as per actual code ) would that type of information still not be persuasive? BTW: exactly where did u get the idea that I was advocating cut&paste of someone-else's code? You learn by reading other peoples code. And if you read enough you can sometimes perceive software genealogy. Oberhuber, Martin wrote: > U.George wrote: > BTW: Since JAVA source went public, sorta, did java publish the > commapi source? > > Sun is publishing the OpenJDK under GPL 2 (with "classpath exception" > for > SOME files only, see the last paragraph of following link): > http://openjdk.java.net/legal/gplv2+ce.html > whereas RXTX is under (modified) LGPL. > > Please DONT go copy&paste GPL'd Sun code into LGPL'd RXTX. > > That would be a BIG problem at least for some companies using RXTX. > GPL is viral in that it might force companies open-source their > proprietary stuff if they link against a GPL'd lib! LGPL is not that > viral, at least not when linking dynamically. We'd really have a > problem when RXTX is infected with GPL'd code fragments. > > Therefore, please DONT even try finding the GPL'd Sun code, > read it or reference it otherwise. It's really a big threat. > Really. > > Thanks, > Martin > > From hunor.bartha at ambo.ro Tue Dec 11 11:55:24 2007 From: hunor.bartha at ambo.ro (Bartha Hunor) Date: Tue, 11 Dec 2007 20:55:24 +0200 Subject: [Rxtx] rxtxParallel problem Message-ID: <475EDD1C.2040002@ambo.ro> Hi, Hope somebody is reading this :). I have been using RXTX for serial communication in my java application and it all worked beautifully, but recently i tried to use the parallel port, and i had no success. I get the infamous link error: Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxParallel in java.library.path at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.LPRPort.(LPRPort.java:35) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java:810) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:343) If i remove all the parallel port related code from my class and leave only the code that uses the serial port everything works ok, the rxtxSerial dll is successfully loaded. I want to mention that the two dll's are in the same directory so i don't understand why is the rxtxSerial.dll found but not the rxtxParallel.dll. I suspect that there is a problem with the parallel dll. I searhced the web about this but i could find little data on people actually using rxtx for parallel communication. Is there anybody who successfully used this under Windows XP SP2 and JDK 1.5? Thanks, hunor From hhinze at gno.de Wed Dec 12 02:54:14 2007 From: hhinze at gno.de (hhinze at gno.de) Date: Wed, 12 Dec 2007 10:54:14 +0100 (CET) Subject: [Rxtx] RXTX and Bluetooth Message-ID: <17538664.1197453254852.JavaMail.ngmail@webmail19> Hi everybody, I'm experiencing some problems when trying to use the rxtx package to access a Bluetooth module. I hope this is the right place to ask. What I want to do is: accessing data in Flash (Windows XP) which have been sent by a microcontroller. Therefor I want to send the data from a serial port to a net port to be accessed over an IP. I use a RN-41 (Roving Networks) Bluetooth module with the Microcontroller. I can connect it with a Bluetooth dongle and get a usual serial COM port. This port can be connected to via several terminal progs (like Eltima e.g.) Then it's possible to communicate with the microcontroller over this terminal. What doesn't work is: when I try to connect to the "Bluetooth port" via the rxtx package it's invisible. I get a NoSuchPortException. It's only visible while I'm connected to the port with one of those terminal progs. But then the port is locked by the other application of course and can't be used. When I connect the microcontroller physically over a USB cable all works fine and I can use my rxtx server. I'm in the middle of my graduation project so I appreciate any help. Thanx Henner Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT F?R ALLE NEUEINSTEIGER Jetzt bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 29,95 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From Martin.Oberhuber at windriver.com Wed Dec 12 06:21:14 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 12 Dec 2007 14:21:14 +0100 Subject: [Rxtx] RXTX and Bluetooth In-Reply-To: <17538664.1197453254852.JavaMail.ngmail@webmail19> References: <17538664.1197453254852.JavaMail.ngmail@webmail19> Message-ID: <460801A4097E3D4CA04CC64EE648584803DB233E@ism-mail03.corp.ad.wrs.com> Hello Henner, try telling RXTX explicitly your port name: One option of doing so is System.setProperty("gnu.io.rxtx.SerialPorts", "YourPortName0"); for more details about manually specifying ports, see the source code in RXTXCommDriver.registerSpecifiedPorts(int) Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of hhinze at gno.de Sent: Wednesday, December 12, 2007 10:54 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX and Bluetooth What doesn't work is: when I try to connect to the "Bluetooth port" via the rxtx package it's invisible. I get a NoSuchPortException. It's only visible while I'm connected to the port with one of those terminal progs. But then the port is locked by the other application of course and can't be used. From Martin.Oberhuber at windriver.com Wed Dec 12 06:34:26 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 12 Dec 2007 14:34:26 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475ED8BA.6040403@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> <475ED8BA.6040403@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803DB2354@ism-mail03.corp.ad.wrs.com> Hi George, > exactly where did u get the idea that I was advocating > cut&paste of someone-else's code? You learn by reading > other peoples code. And if you read enough you can > sometimes perceive software genealogy. no offence meant, I didn't think you were advocating copy& paste. I just wanted people to be aware of potential GPL problems, and thus be careful. I'm not a lawyer, so I cannot guarantee that the following is true: but in my understanding, reading code in order to get ideas does not violate copyright because only a specific expression of code (read: verbatim copy) can be copyrighted. Algorithms, code structures and APIs can be patented but not copyrighted; thus, in terms of GPL'd code, only verbatim copy & paste is a real threat. That being said, reading DOCs should be OK. Even talking about particular aspects of implementation _should_ be OK. Still, I personally prefer being over-careful and not even digging into GPL code looking for information, if I can avoid it. Code scanners like BlackDuck will find code that has been taken from somewhere else. And if Sun wanted to be malicious to other companies, taking the GPL as a weapon, they have everything they need. So again, please be careful and use good judgement. Getting RXTX GPL-infested would be a problem for us. Thanks, Martin From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0011.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0009.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0009.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0008.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0006.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment-0006.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From ajmas at sympatico.ca Sat Dec 8 08:13:26 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 8 Dec 2007 10:13:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> On 7-Dec-07, at 14:26 , Beat Arnet wrote: > > On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. > > > Well, that's certainly what you get when electrical engineers like > me write software ;) > > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > > > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. If you can you should assign the responsibility of closing the port to the one handling the port. The other thread should simply be telling the handling thread that it should close the port. Threads are like people, in that if you give them conflicting instructions all hell breaks loose. For example of what I think you should do: class MyClass { private boolean continueReading = true; public void run() { InputStream in = null; try { in = createMyInputStream(); // or however int len = 0; byte[] buffer = new byte[1024]; while ( (len = in.read(buffer)) > 0 && continueReading ) { // handle the read data } } catch ( IOException ex ) { } finally { if ( in != null ) { in.close(); } } } } Andre From netbeans at gatworks.com Sat Dec 8 16:25:43 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 08 Dec 2007 18:25:43 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: <475B27F7.5040500@gatworks.com> >> But I am not talking about multiple threads reading from the same >> port. I am dealing with a case in which one thread is reading from the >> port, and another wants to close the port. > So I looked at the RXTX code ( close(), read() ) ( is that what u were trying to point out ? ) and it seems that a close() may not close. If there is heavy reading, then maybe close wont happen at all. Not sure why read is synchronized. If someone wants to read - uncoordinated, then that his option! But the read() and the close() does not appear to have a strong method of synchronization ( close should set a flag, that would cause any further I/O requests to throw an exception ). On would think that a close() would also prevent any further write() operations. But it does not. It also does not appear to wait for the write( b[] ) to complete ( in case the array has to be written out in chunks bec the kernel buffer is full. ) Does this help any? :-} From vorobyev.a at gmail.com Sun Dec 9 01:31:05 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Sun, 09 Dec 2007 11:31:05 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475BA7C9.6090900@gmail.com> Good day. Following problem: Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Java 6 - 1.6.02 OS OpenSuse 10.3, 2.6.22.13-0.3-default I have attach USB printer: Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device found, idVendor=088c, idProduct=2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Product: TTP 2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Manufacturer: Swecoin AB Dec 8 09:25:46 linux-fceg kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x088C pid 0x2030 Dec 8 09:25:46 linux-fceg kernel: usbcore: registered new interface driver usblp Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver linux-fceg:/var/log # ll /dev/usb* lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 Example: Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { CommPortIdentifier portIdentifier = (CommPortIdentifier) portEnum.nextElement(); System.out.println(portIdentifier.getName() + " - " + getPortTypeName(portIdentifier.getPortType())); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial Virtual LPT port not found... Parallel port /dev/lp0 not foud also. After that i modified source RXTXCommDriver.java, registerScannedPorts if (osName.equals("Linux") { String[] temp = { "lp", // linux printer port "usblp" <====================== add this }; CandidatePortPrefixes = temp; } else if (osName.equals("FreeBSD")) { But /dev/usblp0 not found anyway. After that i modified registerValidPorts if (osName.equals("Solaris") || osName.equals("SunOS")) { checkSolaris(PortName, PortType); } else { if (PortType==CommPortIdentifier.PORT_PARALLEL) <<<< i.e. port type is parallel - don't execute testRead CommPortIdentifier.addPortName( PortName,PortType,this); <<<< else if (testRead(PortName, PortType)) CommPortIdentifier.addPortName( PortName,PortType,this); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial /dev/usblp0 - Parallel /dev/lp0 - Parallel I think, what native testRead incorrectly defines presence of parallel port. I think that presence parallel port can be checked up so: int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) // port is not exist or it is not parallel port else // port is parallel! After that i execute program: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 5000); String str = "12313212312313121231321231231312"; port.getOutputStream().write(str.getBytes()); port.close(); Result: RXTXCommDriver:getCommPort(/dev/usblp0,2) LPRPort:LPRPort(/dev/usblp0) Port /dev/usblp0 in use by another application gnu.io.PortInUseException: Unknown Linux Application linux-fceg:/var/log # lsof | grep /dev/usb I.e. port is not use. Similar result at use /dev/lp0 How i can use parallel ports in my program? PS: Sorry for my english :) From tjarvi at qbang.org Sun Dec 9 00:03:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 00:03:51 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: On Sat, 8 Dec 2007, U. George wrote: >>> But I am not talking about multiple threads reading from the same >>> port. I am dealing with a case in which one thread is reading from the >>> port, and another wants to close the port. >> > So I looked at the RXTX code ( close(), read() ) ( is that what u were > trying to point out ? ) and it seems that a close() may not close. If > there is heavy reading, then maybe close wont happen at all. > > Not sure why read is synchronized. If someone wants to read - > uncoordinated, then that his option! > But the read() and the close() does not appear to have a strong method > of synchronization ( close should set a flag, that would cause any > further I/O requests to throw an exception ). > > On would think that a close() would also prevent any further write() > operations. But it does not. It also does not appear to wait for the > write( b[] ) to complete ( in case the array has to be written out in > chunks bec the kernel buffer is full. ) > Hi George, The code may not look conventional because I wasnt looking at other code at the time. It does do close to what you expect. The code got there the hard way though. close sets the fd to 0 which should throw exceptions if you try IO. while( IOLocked > 0 ) should delay close while reading and writing are in progress. In write(b[]) the following code can be found (comments added): // throw exception if closed. if ( fd == 0 ) throw new IOException(); // prevent closing while writing. IOLocked++; // Ensure the event thread is not being setup. ie // open() waitForTheNativeCodeSilly(); read() has the same logic (deleting some code for clairity) if ( fd == 0 ) throw new IOException(); IOLocked++; waitForTheNativeCodeSilly(); The close(): (for clairity just the code that we care about here:) while( IOLocked > 0 ) { sleep() } removeEventListener(); nativeClose( this.name ); fd = 0; -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 03:35:47 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 05:35:47 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475BA7C9.6090900@gmail.com> References: <475BA7C9.6090900@gmail.com> Message-ID: <475BC503.7010708@gatworks.com> > > linux-fceg:/var/log # ll /dev/usb* > lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 I suppose this is your first issue i would have expected a /dev/usblp0 ->/dev/lp1 ( since most machines have a /dev/lp0 ) > > result: > /dev/ttyS2 - Serial > /dev/ttyS1 - Serial > /dev/ttyS0 - Serial > Virtual LPT port not found... Parallel port /dev/lp0 not foud also. thats bec lp0 its in /dev/usb ! > > LPRPort:LPRPort(/dev/usblp0) > Port /dev/usblp0 in use by another application > gnu.io.PortInUseException: Unknown Linux Application rxtx code: int fd = open( filename, O_RDWR | O_NONBLOCK ); rxtx appears to want to be able to open the device for reading AND writing. I suspect permission failure. 1) anyway have a symbolic pointer from /dev/usb/usblp0 to /dev/lp0 2) change permissions to be RW for you group or owner. From netbeans at gatworks.com Sun Dec 9 04:44:35 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 06:44:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <475BD523.3000900@gatworks.com> > close sets the fd to 0 which should throw exceptions if you try IO. Setting fd to 0 appears to be the last step in rxtx-close. It should be the first step, as a mutex to prevent any further I/O to the channel. With hyperthreads, quad cpu's, other threads can be simultaneously ( in real time ) executing reads & writes & other things. > > while( IOLocked > 0 ) should delay close while reading and writing are > in progress. Yes, but there is nothing there to prevent any further user I/O. You could have a bunch of threads continue to read & write, and keep IOLock > 0 for some time. Even if it did reach IOLock reached 0, there is still the possibility of some thread upping IOLock inbetween. > > In write(b[]) the following code can be found (comments added): > > // throw exception if closed. > if ( fd == 0 ) throw new IOException(); > // prevent closing while writing. Where is the "prevent further writing while closing" ? > > (for clairity just the code that we care about here:) > > while( IOLocked > 0 ) > { sleep() } this can take a long time to process. And defeats the purpose of a close() at time x. Because at time x+1, any further user requests to that file descriptor should have failed. One also has to ask why is the user program still reading or writing after having the close() called? But that is for the user to figure out. The orig question posed was to have a multi cpu, and 2 java threads. 1 thread was reading, while the other was ( attempting to ) closeing. probably something like this should be done: public close() { synchonize( eis ) { we_are_closing_up = true; while ( IOLock > 0 ) sleep( 100ms ); } native_close(); fd = 0; } we_are_closing_up = false; } public write() { if ( we_are_closing_up ) synchronize( eis ) { ; } if ( fd == 0 ) throw ( ..... IOLock++; ...... this is also not perfect. There is the possibility that a close could happen after the test, and before the IOLock++ From beat.arnet at gmail.com Sun Dec 9 05:44:23 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 09 Dec 2007 07:44:23 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475BE327.9010709@gmail.com> Thanks to all for responding to my original question! From what I hear, we now suspect that some improvements in RXTX might be necessary to make the code 100% thread safe. I would be happy to help, but I fear that I might not quite have the necessary training/skills. Maybe with some guidance I could give it a try. Since there has been no official release since 2.1.7, I am also wondering where I should start in the trunk so that I can be sure that all valid bug fixes that have been submitted sine 2.1.7 are included. However, I would also like to find out if there is something short-term that I can do in my application to avoid dead-locks on dual core machines, before RXTX is fixed. After Daniel's response, I synchronized all RXTXPort accesses, but I have still some crashes being reported from the field, albeit much less (and possibly unrelated?). Should I setup my code such that all accesses to the serial port happen in one unique thread? Would this prevent the problems that are described below? Any further guidance from the group would be appreciated. Regards, Beat U. George wrote: >> close sets the fd to 0 which should throw exceptions if you try IO. >> > Setting fd to 0 appears to be the last step in rxtx-close. It should be > the first step, as a mutex to prevent any further I/O to the channel. > With hyperthreads, quad cpu's, other threads can be simultaneously ( in > real time ) executing reads & writes & other things. > > > >> while( IOLocked > 0 ) should delay close while reading and writing are >> in progress. >> > Yes, but there is nothing there to prevent any further user I/O. You > could have a bunch of threads continue to read & write, and keep IOLock > > 0 for some time. > Even if it did reach IOLock reached 0, there is still the possibility of > some thread upping IOLock inbetween. > >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. >> > Where is the "prevent further writing while closing" ? > >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } >> > this can take a long time to process. And defeats the purpose of a > close() at time x. Because at time x+1, any further user requests to > that file descriptor should have failed. > One also has to ask why is the user program still reading or writing > after having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/6b16e64b/attachment-0005.html From tjarvi at qbang.org Sun Dec 9 11:01:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 11:01:00 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > >> close sets the fd to 0 which should throw exceptions if you try IO. > Setting fd to 0 appears to be the last step in rxtx-close. It should be the > first step, as a mutex to prevent any further I/O to the channel. With > hyperthreads, quad cpu's, other threads can be simultaneously ( in real time > ) executing reads & writes & other things. > > >> >> while( IOLocked > 0 ) should delay close while reading and writing are in >> progress. > Yes, but there is nothing there to prevent any further user I/O. You could > have a bunch of threads continue to read & write, and keep IOLock > 0 for > some time. > Even if it did reach IOLock reached 0, there is still the possibility of some > thread upping IOLock inbetween. >> >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. > Where is the "prevent further writing while closing" ? >> >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } > this can take a long time to process. And defeats the purpose of a close() at > time x. Because at time x+1, any further user requests to that file > descriptor should have failed. > One also has to ask why is the user program still reading or writing after > having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 thread > was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could happen > after the test, and before the IOLock++ > There are two questions in the back of my mind. The first is I'd like to see some form of documentation in the Java API that says this is the right behavior. Anything from file IO to network sockets. The second is that we are dealing with perhaps the slowest reads and writes out there. I'd anticipate some downstream impact (incompatability) with people using the current implementation. At least at first, a change like this should be something people opt into via preferences or other means. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 12:17:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 14:17:15 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C3F3B.9050003@gatworks.com> > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. ?? I'm not sure what behavior your are expecting the JAVA docs to explain? I'd be more interested in the OS docs that will/could explain the interaction of threads and the sequencing of I/O operations amongst active cpu instruction pipelines. > > The second is that we are dealing with perhaps the slowest reads and > writes out there. I'd anticipate some downstream impact > (incompatability) with people using the current implementation. At > least at first, a change like this should be something people opt into > via preferences or other means. u mean there are folks that continue to read & write even though they also issued a (premature) close ? I am not aware of any OS that behaves like that. Or allows that. Yes, but if you will notice, the the speed of USB devices, that are made to behave like serial, or parallel devices, are very-very fast. A 500ms sleep is forever on some USB devices. BTW: Since JAVA source went public, sorta, did java publish the commapi source? BTW#2:Your mail to 'Rxtx' with the subject If not DEBUGing, remove useless calls to report() et al Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 46243 bytes with a limit of 40 KB From netbeans at gatworks.com Sun Dec 9 13:00:09 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 15:00:09 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C4949.5060109@gatworks.com> > > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. from Class CommPort: After a communications port has been identified and opened it can be configured with the methods in the low-level classes like SerialPort and ParallelPort. Then an IO stream can be opend for reading and writing data. Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown. From dwippermann at gmx.net Sun Dec 9 13:36:28 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:36:28 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: Hi all, > If you can you should assign the responsibility of closing the port > to the one > handling the port. The other thread should simply be telling the > handling thread > that it should close the port. Threads are like people, in that if > you give them > conflicting instructions all hell breaks loose. For example of what > I think you > should do: > yes, that you be the common way if I had full control over the thread. But the thread is implemented and started by RXTX, I only get event through my listener. How should the listener be able to close the port if no event is triggered? Can I wake up the RXTX thread to send a dummy event to trigger the close from inside the listener? Daniel From dwippermann at gmx.net Sun Dec 9 13:55:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:55:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: And hi once more, > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ Thats the reason why I encapsulated all access in synchronized blocks using one mutex. You simply have no problem with "after ... , but before..." anymore :) One other problem I see is the use of the ++/-- operators on a variable that can be accessed by mutliple threads in parallel. I'll run a short test tomorrow on my office machine, but I assume that its read-modify-write behaviour might bring up a collision like: IOLocked = 100, both thread are running in different CPUs, but due to timing arrive at the "IOLocked--" nearly simultaneously CPU 1: reads variable to register => register = 100 CPU 2: doing something else -- CPU 1: decrements register => register = 99 CPU 2: reads variable to register => register = 100 -- CPU 1: writes register to variable => variable = 99 CPU 2: decrements register => register = 99 -- CPU 1: doing something else CPU 2: writes register to variable => variable = 99 It should have decremented twice, but it didn't... Thats a common situtation where locking is needed: modify the same variable from different threads without synchonization is hell :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/4bd9d474/attachment-0004.html From netbeans at gatworks.com Thu Dec 6 04:14:53 2007 From: netbeans at gatworks.com (U. George) Date: Thu, 06 Dec 2007 06:14:53 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al Message-ID: <4757D9AD.2080305@gatworks.com> For the most part the report() calls from everywhere is usefull in debugging whats happening within rxtx. BUT if you are not debugging, then it is just wasted CPU cycles. That also includes the sprintf's sprinkled here and there. I placed the DEBUG code ( SerialImp.c ) under the #ifdef DEBUG . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071206/92c448eb/attachment-0004.pl From tjarvi at qbang.org Sun Dec 9 19:15:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:15:44 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <4757D9AD.2080305@gatworks.com> References: <4757D9AD.2080305@gatworks.com> Message-ID: This looks OK to me George. Just two issues. make_message is probably copyrighted by the Free Software Foundation. It is probably easier to recode it than deal with the minor potential issues. The only other minor issue is that commenting out code isn't really better than deleting it in the long run. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 19:35:41 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 21:35:41 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> Message-ID: <475CA5FD.6050801@gatworks.com> Trent Jarvi wrote: > > This looks OK to me George. Just two issues. > > make_message is probably copyrighted by the Free Software Foundation. > It is probably easier to recode it than deal with the minor potential > issues. code u refer to is not used. I'm not too sure if "all" cc/libs can handle the particular var-args scheme. So if blows up, then that becomes an issue, but not harmfull for anybody's run. I did want to use it to do: REPORT("FIONREAD failed with error %s\n", strerror( errno )); or more recently REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); Since u PORT this to other machines, its not clear if var-args works everywhere the same way. u got any notion? > > The only other minor issue is that commenting out code isn't really > better than deleting it in the long run. > Sorta, sorta not. For short run ( in the heading of small changes ) it looks just like all the other items (historically) commented out, but not yet removed :) More things to clean up for the long run i guess. From tjarvi at qbang.org Sun Dec 9 19:47:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:47:37 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <475CA5FD.6050801@gatworks.com> References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> >> This looks OK to me George. Just two issues. >> >> make_message is probably copyrighted by the Free Software Foundation. It >> is probably easier to recode it than deal with the minor potential issues. > code u refer to is not used. I'm not too sure if "all" cc/libs can handle the > particular var-args scheme. So if blows up, then that becomes an issue, but > not harmfull for anybody's run. > > I did want to use it to do: > REPORT("FIONREAD failed with error %s\n", strerror( errno )); > > or more recently > > REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); > > Since u PORT this to other machines, its not clear if var-args works > everywhere the same way. u got any notion? > >> >> The only other minor issue is that commenting out code isn't really better >> than deleting it in the long run. >> > Sorta, sorta not. For short run ( in the heading of small changes ) it looks > just like all the other items (historically) commented out, but not yet > removed :) More things to clean up for the long run i guess. > So far as I know, var-args works fine on the other platforms. See ioctl in termios.c (w32) for instance. I would rather link to make_message or implement a work alike. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 20:49:44 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 22:49:44 -0500 Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: References: Message-ID: <475CB758.6000508@gatworks.com> rxtx-bounces at qbang.org wrote: > Your mail to 'Rxtx' with the subject > > Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al > > Is being held until the list moderator can review it for approval. I suppose this limitation was a recent change? :/ From tjarvi at qbang.org Sun Dec 9 20:55:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 20:55:33 -0700 (MST) Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: <475CB758.6000508@gatworks.com> References: <475CB758.6000508@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > > rxtx-bounces at qbang.org wrote: >> Your mail to 'Rxtx' with the subject >> >> Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al >> >> Is being held until the list moderator can review it for approval. > > > I suppose this limitation was a recent change? :/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > No. It is just a size limititation. I have upped it in the past. You might consider sending it as a .gz/.zip. Many people end up with full mailboxes and then bounce. The size limitation is 3 years old. The reason I don't get to the deffered email very often is it gets about 1k spams a week. At least we keep the spam out of everyones email box. If you like, I can fish out your email. I'd suggest zipping it though. There are ~500 people on the list but most just want to follow along. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 21:07:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 23:07:15 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: <475CBB73.9080805@gatworks.com> > So far as I know, var-args works fine on the other platforms. See ioctl > in termios.c (w32) for instance. > dont have a win32 development system. At least not a recent one. And not installed anywhere :}} > I would rather link to make_message or implement a work alike. Its not a problem. looks almost like the jprint( ... ). -------------- next part -------------- A non-text attachment was scrubbed... Name: IfDef_patch.gz Type: application/x-gzip Size: 10381 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/5a6ec2c1/attachment-0004.gz From vorobyev.a at gmail.com Mon Dec 10 00:41:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 10:41:32 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475CEDAC.9090907@gmail.com> >2) change permissions to be RW for you group or owner. Thanks, it is my stupid mistake. But usb printer not work anyway. Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; ========================================== test program in c++: void ParallelPort::test(){ int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) return ; printf("status: 0x%02x\n",status); printf("Busy (~status & LP_PBUSY) : %x\n", (~status & LP_PBUSY)); printf("Error (~status & LP_PERRORP): %x\n", (~status & LP_PERRORP)); printf("Select (status & LP_PSELECD) : %x\n", (status & LP_PSELECD)); printf("Paper out (status & LP_POUTPA) : %x\n", (status & LP_POUTPA)); } result: status: 0x18 Busy (~status & LP_PBUSY) : 80 Error (~status & LP_PERRORP): 0 Select (status & LP_PSELECD) : 10 Paper out (status & LP_POUTPA) : 0 ParallelPort port("/dev/usblp0"); port.open(); port.write("Hello world"); port.write(0x1e); // cut port.close(); Result: Device print data and cut paper. ========================================== test program in java: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 50000); System.out.println("paper out: "+ port.isPaperOut()); System.out.println("buzy: "+ port.isPrinterBusy()); System.out.println("error: "+ port.isPrinterError()); System.out.println("select: "+ port.isPrinterSelected()); System.out.println("timeout: "+ port.isPrinterTimedOut()); result: paper out: true buzy: false error: false select: false timeout: false From netbeans at gatworks.com Sun Dec 9 22:04:46 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 00:04:46 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475CEDAC.9090907@gmail.com> References: <475CEDAC.9090907@gmail.com> Message-ID: <475CC8EE.9040205@gatworks.com> Alexander Vorobyev wrote: >> 2) change permissions to be RW for you group or owner. > Thanks, it is my stupid mistake. > > But usb printer not work anyway. > Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; I suppose the USB/LP driver may not be sophisticated enough to provide that information, presuming that information is at all relevant to the device itself ( like a parallel port Zip Drive ). From vorobyev.a at gmail.com Mon Dec 10 01:46:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 11:46:32 +0300 Subject: [Rxtx] One more question about usb->lpt Message-ID: <475CFCE8.3080807@gmail.com> Good day I wrote about the arisen problems at work with the device/dev/usb/lp0. At use c ++ work with the given device is made easily enough. Example void Usb2Lpt::open(){ handle = ::open(this->device.c_str(),O_RDWR|O_NOCTTY|O_NDELAY); if (handle<0) throw FileNotOpenException(strerror(errno)); } void Usb2Lpt::close(){ ::close(handle); handle = -1; } void Usb2Lpt::waitForRead(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, &rfds, NULL, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } void Usb2Lpt::waitForWrite(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, NULL, &rfds, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } unsigned char* Usb2Lpt::read(uint size){ .... r = ::read(handle,buf,len); ... return buf; } int Usb2Lpt::write(char data){ int w; waitForWrite(); w = ::write(handle,&data,sizeof(data)); if (w==-1){ if (errno==EAGAIN) return 0; else throw IOException(strerror(errno); } return w; } I.e. it is work as write/read + blocking/nonblocking mode; It is how much easy to make support of such driver in library rxtx? From zhouzhao58 at 163.com Mon Dec 10 05:13:14 2007 From: zhouzhao58 at 163.com (=?GBK?B?1tzuyA==?=) Date: Mon, 10 Dec 2007 20:13:14 +0800 (CST) Subject: [Rxtx] Help me ,please Message-ID: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> I used a common-user in the MAC OS 10.5. When i used rxtx 2.1.7 to open the serial port on the MAC OS 10.5.the rxtx has a error. how can I do ? thanks description: error testing lock file creation error details:permission deniedcheck_lock_status:no perminssion to create lock file. please see: how can I use lock files with rxtx ? in install -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/0ebc8026/attachment-0004.html From dwippermann at gmx.net Mon Dec 10 05:29:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 13:29:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Hi again, > One other problem I see is the use of the ++/-- operators on a > variable that can be accessed by mutliple threads in parallel. I'll > run a short test tomorrow on my office machine, but I assume that > its read-modify-write behaviour might bring up a collision like: > > IOLocked = 100, both thread are running in different CPUs, but due > to timing arrive at the "IOLocked--" nearly simultaneously > > CPU 1: reads variable to register => register = 100 > CPU 2: doing something else > -- > CPU 1: decrements register => register = 99 > CPU 2: reads variable to register => register = 100 > -- > CPU 1: writes register to variable => variable = 99 > CPU 2: decrements register => register = 99 > -- > CPU 1: doing something else > CPU 2: writes register to variable => variable = 99 > > It should have decremented twice, but it didn't... Thats a common > situtation where locking is needed: modify the same variable from > different threads without synchonization is hell :) Small sample app: (((snip))) public class Main { static Object mutex; static int counter; public static void concurrencyTest(final boolean useMutex) { Runnable r = new Runnable() { public void run() { synchronized(mutex) { try { mutex.wait(); } catch (Exception ex) { ex.printStackTrace(); } } for (int i = 0; i < 1000000; i++) { if (useMutex) { synchronized (mutex) { counter++; } } else { counter++; } } } }; try { counter = 0; mutex = new Object(); Thread t1 = new Thread(r); Thread t2 = new Thread(r); // start the two threads, they will wait for the mutex to be signaled t1.start(); t2.start(); // just a little sleep before the work Thread.sleep(100); synchronized (mutex) { // signal the two threads to start working mutex.notifyAll(); } t1.join(); t2.join(); System.out.println("useMutex = " + useMutex + " => counter = " + counter); } catch (Exception ex) { ex.printStackTrace(); } } public static void main(String[] args) { concurrencyTest(true); concurrencyTest(false); } } (((snip))) The program starts two threads. Each thread should increment a counter 1 million times, hence you expect a result of 2 million. Haven't tested it on a single-core machine, but on my multi-core office machine I get: useMutex = true => counter = 2000000 useMutex = false => counter = 1221835 The second result is fluctuating heavily. By that example I want to demonstrate that the use of "IOLocked++" for locking purposes is by far not thread-safe. And if you have heavy trafiic over the serial port (as I have, up to 2,8 MB of data to transceive at 115kbps), the chance of synchronization issues is reasonable. The only possibility I have to counter this at the moment is to synchronize all function calls to RXTX, especially close(), getInputStream(), read() as well as getOutputStream() and write(). It cannot be taken as a general advise to solve this problem, because synchronization has to fit into thr rest of your app. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/99aca116/attachment-0004.html From netbeans at gatworks.com Mon Dec 10 06:59:29 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 08:59:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D4641.7050001@gatworks.com> > By that example I want to demonstrate that the use of "IOLocked++" for > locking purposes is by far not thread-safe. And if you have heavy > trafiic over the serial port (as I have, up to 2,8 MB of data to > transceive at 115kbps), the chance of synchronization issues is reasonable. Synchronization of read/writes should be handled by the user. There is nothing in rxtx that will disturb the synchronization, as it is not an rxtx function. If a user wants to have 3 threads writing to that device, its up to the user to coordinate the proper sequencing of writes. The synchronize reads in SerialImp/read() appear to be a violation of the abstract class InputStream. If you want 3 threads simultaneously reading from that device, then thats up to the users application to determine the sequence for access. The IOLocked is a flag to indicate that a read/write I/O operation is in progress. it does not lockout the other from happening simultaneously. The synchronize read() does prevent simultaneous reads from multiple threads. The IOLocked indicator does prevent the close() from starting up, as close() waits for the IOLock value to become 0. The presumption is that the application's reads/writes will cease because the application has issued a close(). You wouldnt issue any further I/O after the close - would you? From dwippermann at gmx.net Mon Dec 10 07:53:03 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 15:53:03 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi all, > The IOLocked is a flag to indicate that a read/write I/O operation > is in > progress. it does not lockout the other from happening simultaneously. > The synchronize read() does prevent simultaneous reads from multiple > threads. > The IOLocked indicator does prevent the close() from starting up, as > close() waits for the IOLock value to become 0. The presumption is > that > the application's reads/writes will cease because the application has > issued a close(). You wouldnt issue any further I/O after the close - > would you? You are completely right, I never meant to imply something different. The IOLocked shall not lock concurrent reads or concurrents writes away, but be a signal for the close method that some read or write is still underway and it has to wait for them to finish. But the original question was, why the IOLocked variable has a value ! = 0 ALTHOUGH all read and write activities have ceased quite a while ago? And there were only two threads involved: on one side the thread that called open() and write() and on the other side the RXTX monitor thread that calling read(). No multiple reads or writes! Only a parallel write while reading. But that cannot be forbidden since we talk about an USART. Or am I wrong? Is there a problem to to have one read() and one write() run simulatenously? If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/db7e990f/attachment-0003.html From netbeans at gatworks.com Mon Dec 10 10:17:26 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 12:17:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D74A6.4000209@gatworks.com> > If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). i suppose u mean that the IOLocked++, and the IOLocked-- has to be accomplished atomically ? I suppose besides meaning that you would also like that? :} From dwippermann at gmx.net Mon Dec 10 10:22:40 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:22:40 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi everone, > Hi all, >> The IOLocked is a flag to indicate that a read/write I/O operation >> is in >> progress. it does not lockout the other from happening >> simultaneously. >> The synchronize read() does prevent simultaneous reads from multiple >> threads. >> The IOLocked indicator does prevent the close() from starting up, as >> close() waits for the IOLock value to become 0. The presumption is >> that >> the application's reads/writes will cease because the application has >> issued a close(). You wouldnt issue any further I/O after the close - >> would you? > You are completely right, I never meant to imply something > different. The IOLocked shall not lock concurrent reads or > concurrents writes away, but be a signal for the close method that > some read or write is still underway and it has to wait for them to > finish. > But the original question was, why the IOLocked variable has a > value != 0 ALTHOUGH all read and write activities have ceased quite > a while ago? And there were only two threads involved: on one side > the thread that called open() and write() and on the other side the > RXTX monitor thread that calling read(). No multiple reads or > writes! Only a parallel write while reading. But that cannot be > forbidden since we talk about an USART. Or am I wrong? Is there a > problem to to have one read() and one write() run simulatenously? > If that case is an allowed one, IOLocked has to be synchronized > because it is altered in read() and write(). I've prepared a patch to RXTXPort.java to help me outline my point of view in this discussion. It's attached to this posting. In general, three things have been done: 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be passed as a parameter to the synchronized statement. 2) Every "IOLocked++" is encapsulated by that said synchronized block 3) In some methods there were multiple "IOLocked--". Those have all been substituted by a one synchronized "IOLocked--" which is processed in a "finally" statement that handles all exceptions from right after "IOLocked++" till the end of the method. So every occurence or variation of the sequence: > IOLocked++; > waitForTheNativeCodeSilly(); > try { > // something method specific here > } catch (IOException ex) { > IOLocked--; > throw ex; > } > IOLocked--; has been replaced by: > synchronized (IOLockedMutex) { > IOLocked++; > } > try { > waitForTheNativeCodeSilly(); > // something method specific here > } finally { > synchronized (IOLockedMutex) { > IOLocked--; > } > } In my opinion that chance has no impact on the surrounding application. It wont block away one function call if another one is running, it only ensures, that only one thread alters the IOLocked variable at any given time. So you could have one polling read() and one write() action in parallel without interference. In the hope, that I haven't abused your patience too much :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0006.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RXTXPort_IOLockedMutex.diff Type: application/octet-stream Size: 6297 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0003.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0007.html From dwippermann at gmx.net Mon Dec 10 10:44:17 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:44:17 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Hi! > i suppose u mean that the IOLocked++, and the IOLocked-- has to be > accomplished atomically ? > > I suppose besides meaning that you would also like that? :} Yes, indeed... I was lacking the word "atomically", but at least you were able to follow my remaining semi-english explanation :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/5f88033d/attachment-0003.html From netbeans at gatworks.com Mon Dec 10 14:03:38 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 16:03:38 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DA9AA.90106@gatworks.com> According to this (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): > A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking. It appears that "volatile" makes concurrent updates atomic. Its not intuitive. So is it true ? Daniel Wippermann wrote: > Hi! > >> i suppose u mean that the IOLocked++, and the IOLocked-- has to be >> accomplished atomically ? >> >> I suppose besides meaning that you would also like that? :} > Yes, indeed... I was lacking the word "atomically", but at least you > were able to follow my remaining semi-english explanation :) > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dwippermann at gmx.net Mon Dec 10 14:33:02 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 22:33:02 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: Hi, > According to this > (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html > ): > > A write to a volatile field happens-before every subsequent read > of that same field. Writes and reads of volatile fields have similar > memory consistency effects as entering and exiting monitors, but do > not entail mutual exclusion locking. > > It appears that "volatile" makes concurrent updates atomic. Its not > intuitive. So is it true ? > I tried the volatile declaration on my small ConcurrencyTest app. It has no effect, the unsynchronized version still misses a vast amount of increments. I think that the read-modify-write behaviour of "++" and "--" is not covered by the "happens-before" clause of the volatile declaration. It only ensures, that the corresponding read and write operations are not interrupted, the time in between these operations is not covered. Although it sounded promising on the first look... I can't imagine a different working approach to get IOLocked thread- safe at the moment. But perhaps I'm stuck and just have to think about it another night or two... Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/d13a0db5/attachment-0003.html From netbeans at gatworks.com Mon Dec 10 15:32:42 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 17:32:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DBE8A.8050408@gatworks.com> I suspect that what they said is not exact. My impression, at one time, was that the volatile object could not be optimized into not writing to memory. Oh well. Have you tried java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? from jdk1.5 and beyond? these set of utilities have an interesting way of 'atomically' incrementing the variable. I'd be curious if your test would also fail using these utilities. Daniel Wippermann wrote: > Hi, > >> According to this >> (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): >> >/ A write to a volatile field happens-before every subsequent read of >> that same field. Writes and reads of volatile fields have similar >> memory consistency effects as entering and exiting monitors, but do >> not entail mutual exclusion locking. / It appears that "volatile" >> makes concurrent updates atomic. Its not intuitive. So is it true ? > > > I tried the volatile declaration on my small ConcurrencyTest app. It has > no effect, the unsynchronized version still misses a vast amount of > increments. > > I think that the read-modify-write behaviour of "++" and "--" is not > covered by the "happens-before" clause of the volatile declaration. It > only ensures, that the corresponding read and write operations are not > interrupted, the time in between these operations is not covered. > Although it sounded promising on the first look... > > I can't imagine a different working approach to get IOLocked thread-safe > at the moment. But perhaps I'm stuck and just have to think about it > another night or two... > > Daniel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com.cn Mon Dec 10 19:22:23 2007 From: zhanglong at adventnet.com.cn (zl) Date: Tue, 11 Dec 2007 10:22:23 +0800 Subject: [Rxtx] Homestay 2008 Beijing Olympic Message-ID: <475DF45F.5030702@adventnet.com.cn> Do you want to come to Beijing for 2008 Olympic? Please choose homestay for your accommodation and select my home. Introduction: The whole apartment is furnished in traditional Chinese Style. All furniture is brand new. There are two bedrooms, a modern kitchen, a living room, one bathrooms and one storageroom. It has all the gadgets and amenities including ADSL internet connection, on-demand cable, washer, fridge, microwave, a 25 inch television set, home security system.And community body guard is also included. 24 hours hot water services, local banking facilities,air conditioners are available. Everything is comfortable for living, also supermarket(Carrefour is 5 minuters), park, school, restaurants, entertainment places is surrounding. It's about 10 minutes' drive to the National Stadium (the Bird Nest), and no longer than 5 minutes' walk to the Olympics Forest Park. The subway line 13 and 5 's station of Lishuiqiao is 5-10 minutes' walking distance. For more detail and pictures,Please look at: http://picasaweb.google.com/zlong6688/HomestayBeijing2008 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249599243132994 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249629307904114 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096615126729827426 Contact me: E-mail: zhanglong at adventnet.com.cn Mobile: 13241969320 MSN:zlong6666 at hotmail.com PS: Please help me tell this message to your friends. And you can post this message with no limit. (End) ------------------------------------------------- From dwippermann at gmx.net Mon Dec 10 22:02:59 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 06:02:59 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Hi, > I suspect that what they said is not exact. My impression, at one > time, > was that the volatile object could not be optimized into not writing > to > memory. Oh well. > > Have you tried > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? > from jdk1.5 and beyond? > > these set of utilities have an interesting way of 'atomically' > incrementing the variable. I'd be curious if your test would also fail > using these utilities. thanks for that hint, an interesting package :) This class works as expected and is way faster (at least on my machine) that synchronizing the increment manually. The only drawback - as you mentioned before - is that it requires Java5 to run... And as far as I understand, RXTX targets 1.3 and later JREs... But an eyecatcher indeed, thanks again. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/376692e5/attachment-0003.html From netbeans at gatworks.com Tue Dec 11 05:28:29 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 07:28:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Message-ID: <475E826D.40609@gatworks.com> u didnt catch it all. although introduced in 1.5, those same folks ( not sun ) who made that stuff public domain, also created a 1.4 version, and a 1.3 version. Those backward compatable routines are 'synchronize'd, so should run no better that what rxtx is currently doing. BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx synchronize directives be completely removed from reads and writes ( as well as the removal of IOLocked et al ) ? Daniel Wippermann wrote: > Hi, > >> I suspect that what they said is not exact. My impression, at one time, >> was that the volatile object could not be optimized into not writing to >> memory. Oh well. >> >> Have you tried >> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? >> from jdk1.5 and beyond? >> >> these set of utilities have an interesting way of 'atomically' >> incrementing the variable. I'd be curious if your test would also fail >> using these utilities. > > thanks for that hint, an interesting package :) > > This class works as expected and is way faster (at least on my machine) > that synchronizing the increment manually. > > The only drawback - as you mentioned before - is that it requires Java5 > to run... And as far as I understand, RXTX targets 1.3 and later JREs... > > But an eyecatcher indeed, thanks again. > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Tue Dec 11 08:48:41 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 11 Dec 2007 10:48:41 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475E826D.40609@gatworks.com> References: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <475E826D.40609@gatworks.com> Message-ID: I confirmed Daniel's theory by running his example on both a dual-core and single-core machine. Both counter results are identical on a single core machine, and differ on dual cores. I then tried the synchronized and concurrent.atomic approach and noticed that they both make RXTXPort unbearably slow. Thanks for all your help! Beat On Dec 11, 2007 7:28 AM, U. George wrote: > u didnt catch it all. although introduced in 1.5, those same folks ( not > sun ) who made that stuff public domain, also created a 1.4 version, and > a 1.3 version. Those backward compatable routines are 'synchronize'd, so > should run no better that what rxtx is currently doing. > > > BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx > synchronize directives be completely removed from reads and writes ( as > well as the removal of IOLocked et al ) ? > > Daniel Wippermann wrote: > > Hi, > > > >> I suspect that what they said is not exact. My impression, at one time, > >> was that the volatile object could not be optimized into not writing to > >> memory. Oh well. > >> > >> Have you tried > >> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? > >> from jdk1.5 and beyond? > >> > >> these set of utilities have an interesting way of 'atomically' > >> incrementing the variable. I'd be curious if your test would also fail > >> using these utilities. > > > > thanks for that hint, an interesting package :) > > > > This class works as expected and is way faster (at least on my machine) > > that synchronizing the increment manually. > > > > The only drawback - as you mentioned before - is that it requires Java5 > > to run... And as far as I understand, RXTX targets 1.3 and later JREs... > > > > But an eyecatcher indeed, thanks again. > > > > Daniel > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/356ff730/attachment-0002.html From dwippermann at gmx.net Tue Dec 11 08:50:07 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 16:50:07 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Message-ID: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Hi all, > Those backward compatable routines are 'synchronize'd, so > should run no better that what rxtx is currently doing. Why do you think so? All write() methods in the SerialOutputStream class are not synchronized at all at the moment. And the "synchronized" read() methods only forbid to call more than one of them at any given time because they lock the SerialInputStream object they are living in. But they have no locking influence on a concurrent write() and its altering of IOLocked. So rxtx would do much better than what it is currently doing. > BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx > synchronize directives be completely removed from reads and writes > ( as > well as the removal of IOLocked et al ) ? That's not my decision to make, it's more a political question whether the library takes care of it or the end user developer. You can of course remove it all and let the user take care of it... If you ask me personally: I believe it makes perfect sense to do it in the library. The speed impact is marginal. But it touches the integrity of the library state (since IOLocked cannot be influenced directly from outside). If you cannot close the port because an internal variable's content is damaged, that is nothing to be handled by the end user dev. From my point of view it's the library's responsibility. But I'm tired of "defending" my position here. If you think, it is ok how it is done at the moment: fine, let's end that discussion here. That's the advantage of open source and an open mind: just branch, patch and continue :) On a small side note I'd like to thank Trent, Martin and all the other contributors of this project. It's damn good lib and saved me a lot of time in the past. Keep up the good work, guys! Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/78331b1d/attachment-0002.html From Steffen.DETTMER at ingenico.com Tue Dec 11 09:26:30 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 11 Dec 2007 17:26:30 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <20071211162630.GI2253@elberon.bln.de.ingenico.com> * Daniel Wippermann wrote on Tue, Dec 11, 2007 at 16:50 +0100: > > BTW: wouldnt all run a whole lot better ( faster anyway ) if > > the rxtx synchronize directives be completely removed from > > reads and writes ( as well as the removal of IOLocked et al) ? > > If you ask me personally: I believe it makes perfect sense to > do it in the library. The speed impact is marginal. But it > touches the integrity of the library state (since IOLocked > cannot be influenced directly from outside). I agree. The alternative would be to require that each using application needs to serialise any call to lib functions. In Java usually multiple threads are very common, so I think its likely that all applications would need to add some locking around. I'm afraid it would be uncomfortable, difficult and `risky' to use then (and if not locked correctly, strange behavior could happen later on, after tests, and so on... personally I really hate such problems because they are hard to find, so best is to avoid them I think :)). So I think, having (or keeping, with some extensions / fixes) this `threadsafety' as a lib feature keeps rxtx easily usable and everyone would benefit :) > On a small side note I'd like to thank Trent, Martin and all > the other contributors of this project. It's damn good lib and > saved me a lot of time in the past. Keep up the good work, > guys! well said, again I agree! :) Yes, thanks a lot guys!! oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Tue Dec 11 09:40:45 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 17:40:45 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net><6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net><695CE8C6-D794-464A-9550-150C1501A09F@gmx.net><475E826D.40609@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B0F@ism-mail03.corp.ad.wrs.com> Hi all, I haven't had time to follow this thread in too much detail, but Daniel's argument as well as his patch make perfectly sense to me. The modifications he made seem to be required to ensure data integrity in a multi-threaded enviroment, and his methods (add an additional mutex, use try...finally) seem perfectly right to me: ensuring data integrity, without changing any other semantics of the existing implementation (especially read/write concurrency on a higher level). I also agree that data integrity needs to be maintained at the library level, and not offloaded to the client by not using synchronized at all. I can't understand why these modifications should make RXTXPort a lot slower. On modern JVM's, the "synchronized" statement is processed real fast. Beat can you give more background about your measurements? Daniel: thanks for your contributions and your perseverance. Please don't give up and create your own branch of RXTX. We need guys like you in our Open Source Community :-) Thanks Martin ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, December 11, 2007 4:49 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem I confirmed Daniel's theory by running his example on both a dual-core and single-core machine. Both counter results are identical on a single core machine, and differ on dual cores. I then tried the synchronized and concurrent.atomic approach and noticed that they both make RXTXPort unbearably slow. Thanks for all your help! Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/6333f1fa/attachment-0002.html From netbeans at gatworks.com Tue Dec 11 09:44:24 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 11:44:24 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <475EBE68.8030606@gatworks.com> Daniel Wippermann wrote: > Hi all, > >> Those backward compatable routines are 'synchronize'd, so >> should run no better that what rxtx is currently doing. > > Why do you think so? All write() methods in the SerialOutputStream class > are not synchronized at all at the moment. And the "synchronized" read() > methods only forbid to call more than one of them at any given time > because they lock the SerialInputStream object they are living in. But > they have no locking influence on a concurrent write() and its altering > of IOLocked. So rxtx would do much better than what it is currently doing. Because, if you were to use the (AtomicInteger) IOLocked.getAndIncrement(); u would get a hotspot/native operation in JDK1.5 and JDK1.6, but with jdk1.3 & 1.4, with the backward compatible routines, you would get the synchronise'd routine for getAndIncrement. the JDK1.3 backward routine would be just as good as your suggested code: synchronize( oIOLocked ) { IOLocked++; } > >> BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx >> synchronize directives be completely removed from reads and writes ( as >> well as the removal of IOLocked et al ) ? > > That's not my decision to make, it's more a political question whether > the library takes care of it or the end user developer. You can of > course remove it all and let the user take care of it... For some its what the docs say ( or suggest anyway ) > > If you ask me personally: I believe it makes perfect sense to do it in > the library. The speed impact is marginal. But it touches the integrity > of the library state (since IOLocked cannot be influenced directly from > outside). If you cannot close the port because an internal variable's > content is damaged, that is nothing to be handled by the end user dev. > From my point of view it's the library's responsibility. The point being is that IOLocked is not necessary for the integrity or the state of the library. Nor is the ( forced upon you ) synchronized reads. thats an IMHO. > > But I'm tired of "defending" my position here. If you think, it is ok > how it is done at the moment: I'm not sure what u mean? For my USB/serial io device, rxtx spins & spins. So its not OK at the moment. When I remove (unplug) the serial device, it also spins and spins. Also not an OK situation. And I really hate it when a close() refuses to do so! fine, let's end that discussion here. I thought we were addressing bugs. From Martin.Oberhuber at windriver.com Tue Dec 11 09:48:38 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 17:48:38 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475C3F3B.9050003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> U.George wrote: BTW: Since JAVA source went public, sorta, did java publish the commapi source? Sun is publishing the OpenJDK under GPL 2 (with "classpath exception" for SOME files only, see the last paragraph of following link): http://openjdk.java.net/legal/gplv2+ce.html whereas RXTX is under (modified) LGPL. Please DONT go copy&paste GPL'd Sun code into LGPL'd RXTX. That would be a BIG problem at least for some companies using RXTX. GPL is viral in that it might force companies open-source their proprietary stuff if they link against a GPL'd lib! LGPL is not that viral, at least not when linking dynamically. We'd really have a problem when RXTX is infected with GPL'd code fragments. Therefore, please DONT even try finding the GPL'd Sun code, read it or reference it otherwise. It's really a big threat. Really. Thanks, Martin From Martin.Oberhuber at windriver.com Tue Dec 11 10:04:20 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:04:20 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BE327.9010709@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> <475BE327.9010709@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B23@ism-mail03.corp.ad.wrs.com> Hi Beat, > Should I setup my code such that all accesses > to the serial port happen in one unique thread? > Would this prevent the problems that are described? Yes, I think that accessing your RXTXPort from a single thread should work around all the issues discussed here. One option for doing so might be if you create a "frontend" for your RXTXPort like a PipedStream that runs in a single thread but accepts input from multiple threads. Such code could be based on a BoundedBufferWithStateTracking See http://gee.cs.oswego.edu/dl/cpj/allcode.java and http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.core/terminal/or g.eclipse.tm.terminal/src/org/eclipse/tm/internal/terminal/textcanvas/Pi pedInputStream.java?root=DSDP_Project&view=markup Cheers, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/41f74564/attachment-0002.html From Martin.Oberhuber at windriver.com Tue Dec 11 10:05:56 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:05:56 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B26@ism-mail03.corp.ad.wrs.com> U.George wrote: > close should set a flag, that would cause any further > I/O requests to throw an exception ). +1, I fully agree. Cheers, Martin From Martin.Oberhuber at windriver.com Tue Dec 11 10:09:06 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:09:06 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47598A99.2010601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47598A99.2010601@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B2C@ism-mail03.corp.ad.wrs.com> > > try { > > getSerialPort().removeEventListener(); > > Thread.sleep(50); //allow a little time for RXTX Native to catch > > up > > whats there to catch up? > what that a patch for user code? or for RXTX ? This was a "hack workaround" in our user code that helped fixing an issue we had. I don't know why it works, but it works. With all the discusssions we've had so far, it should be possible to make close() thread-safe such that this workaround is not needed any more. Cheers Martin From netbeans at gatworks.com Tue Dec 11 10:11:04 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 12:11:04 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <20071211162630.GI2253@elberon.bln.de.ingenico.com> References: <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> <20071211162630.GI2253@elberon.bln.de.ingenico.com> Message-ID: <475EC4A8.6050204@gatworks.com> > So I think, having (or keeping, with some extensions / fixes) > this `threadsafety' as a lib feature keeps rxtx easily usable and > everyone would benefit :) Being synchronize'd does not guarantee the correct ordering of I/O operations. When the synchronized routine completes, all waiters are woken at the same time, and all have an opportunity ( but not all equal ) to obtain the sync'd routine. That type of coordination is beyond a library. From dwippermann at gmx.net Tue Dec 11 11:08:53 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 19:08:53 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <06C5F84B-E3F7-42E5-8248-42C03251F511@gmx.net> Hi all, > >> Those backward compatable routines are 'synchronize'd, so > >> should run no better that what rxtx is currently doing. > > > > Why do you think so? All write() methods in the SerialOutputStream > class > > are not synchronized at all at the moment. And the "synchronized" > read() > > methods only forbid to call more than one of them at any given time > > because they lock the SerialInputStream object they are living in. > But > > they have no locking influence on a concurrent write() and its > altering > > of IOLocked. So rxtx would do much better than what it is > currently doing. > Because, if you were to use the (AtomicInteger) > IOLocked.getAndIncrement(); u would get a hotspot/native operation in > JDK1.5 and JDK1.6, but with jdk1.3 & 1.4, with the backward compatible > routines, you would get the synchronise'd routine for getAndIncrement. > the JDK1.3 backward routine would be just as good as your suggested > code: > synchronize( oIOLocked ) { > IOLocked++; > } Oh, my fault. When I read "what rxtx is currently doing" I did not include my patch submission, since I do not count it as an official part of RXTX :) But yes, then you are right, it would make no difference in version prior to JDK5 and speed up things for all other versions. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/25160f31/attachment-0002.html From netbeans at gatworks.com Tue Dec 11 11:36:42 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 13:36:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> Message-ID: <475ED8BA.6040403@gatworks.com> The Commapi was not published. Suns philosophy was to have people learn their methods and madness. Sun also believed that you will forget the particular code in a few weeks, rather than the usual 2 years. So it was written. But you seem to forget that in order to replicate the behavior of that code, u need to look at the DOCS. And when that is not specific enough, then there has to be other ways to get that information. For instance the InputStream.read() is not DOC'd as synchronized. Nor is FileInputStream.read synchronized ( as per inspection of the JDK source ). If I further investigate, probably none of the InputStream derivatives are synchronized. Now that I have stated this, does your compliance with DOC's, in the removal of the synchronize, also mean that you adopted another coding license? And if the commapi code were to be published, and did not have the synchronized read ( as per actual code ) would that type of information still not be persuasive? BTW: exactly where did u get the idea that I was advocating cut&paste of someone-else's code? You learn by reading other peoples code. And if you read enough you can sometimes perceive software genealogy. Oberhuber, Martin wrote: > U.George wrote: > BTW: Since JAVA source went public, sorta, did java publish the > commapi source? > > Sun is publishing the OpenJDK under GPL 2 (with "classpath exception" > for > SOME files only, see the last paragraph of following link): > http://openjdk.java.net/legal/gplv2+ce.html > whereas RXTX is under (modified) LGPL. > > Please DONT go copy&paste GPL'd Sun code into LGPL'd RXTX. > > That would be a BIG problem at least for some companies using RXTX. > GPL is viral in that it might force companies open-source their > proprietary stuff if they link against a GPL'd lib! LGPL is not that > viral, at least not when linking dynamically. We'd really have a > problem when RXTX is infected with GPL'd code fragments. > > Therefore, please DONT even try finding the GPL'd Sun code, > read it or reference it otherwise. It's really a big threat. > Really. > > Thanks, > Martin > > From hunor.bartha at ambo.ro Tue Dec 11 11:55:24 2007 From: hunor.bartha at ambo.ro (Bartha Hunor) Date: Tue, 11 Dec 2007 20:55:24 +0200 Subject: [Rxtx] rxtxParallel problem Message-ID: <475EDD1C.2040002@ambo.ro> Hi, Hope somebody is reading this :). I have been using RXTX for serial communication in my java application and it all worked beautifully, but recently i tried to use the parallel port, and i had no success. I get the infamous link error: Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxParallel in java.library.path at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.LPRPort.(LPRPort.java:35) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java:810) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:343) If i remove all the parallel port related code from my class and leave only the code that uses the serial port everything works ok, the rxtxSerial dll is successfully loaded. I want to mention that the two dll's are in the same directory so i don't understand why is the rxtxSerial.dll found but not the rxtxParallel.dll. I suspect that there is a problem with the parallel dll. I searhced the web about this but i could find little data on people actually using rxtx for parallel communication. Is there anybody who successfully used this under Windows XP SP2 and JDK 1.5? Thanks, hunor From hhinze at gno.de Wed Dec 12 02:54:14 2007 From: hhinze at gno.de (hhinze at gno.de) Date: Wed, 12 Dec 2007 10:54:14 +0100 (CET) Subject: [Rxtx] RXTX and Bluetooth Message-ID: <17538664.1197453254852.JavaMail.ngmail@webmail19> Hi everybody, I'm experiencing some problems when trying to use the rxtx package to access a Bluetooth module. I hope this is the right place to ask. What I want to do is: accessing data in Flash (Windows XP) which have been sent by a microcontroller. Therefor I want to send the data from a serial port to a net port to be accessed over an IP. I use a RN-41 (Roving Networks) Bluetooth module with the Microcontroller. I can connect it with a Bluetooth dongle and get a usual serial COM port. This port can be connected to via several terminal progs (like Eltima e.g.) Then it's possible to communicate with the microcontroller over this terminal. What doesn't work is: when I try to connect to the "Bluetooth port" via the rxtx package it's invisible. I get a NoSuchPortException. It's only visible while I'm connected to the port with one of those terminal progs. But then the port is locked by the other application of course and can't be used. When I connect the microcontroller physically over a USB cable all works fine and I can use my rxtx server. I'm in the middle of my graduation project so I appreciate any help. Thanx Henner Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT F?R ALLE NEUEINSTEIGER Jetzt bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 29,95 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From Martin.Oberhuber at windriver.com Wed Dec 12 06:21:14 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 12 Dec 2007 14:21:14 +0100 Subject: [Rxtx] RXTX and Bluetooth In-Reply-To: <17538664.1197453254852.JavaMail.ngmail@webmail19> References: <17538664.1197453254852.JavaMail.ngmail@webmail19> Message-ID: <460801A4097E3D4CA04CC64EE648584803DB233E@ism-mail03.corp.ad.wrs.com> Hello Henner, try telling RXTX explicitly your port name: One option of doing so is System.setProperty("gnu.io.rxtx.SerialPorts", "YourPortName0"); for more details about manually specifying ports, see the source code in RXTXCommDriver.registerSpecifiedPorts(int) Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of hhinze at gno.de Sent: Wednesday, December 12, 2007 10:54 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX and Bluetooth What doesn't work is: when I try to connect to the "Bluetooth port" via the rxtx package it's invisible. I get a NoSuchPortException. It's only visible while I'm connected to the port with one of those terminal progs. But then the port is locked by the other application of course and can't be used. From Martin.Oberhuber at windriver.com Wed Dec 12 06:34:26 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 12 Dec 2007 14:34:26 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475ED8BA.6040403@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> <475ED8BA.6040403@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803DB2354@ism-mail03.corp.ad.wrs.com> Hi George, > exactly where did u get the idea that I was advocating > cut&paste of someone-else's code? You learn by reading > other peoples code. And if you read enough you can > sometimes perceive software genealogy. no offence meant, I didn't think you were advocating copy& paste. I just wanted people to be aware of potential GPL problems, and thus be careful. I'm not a lawyer, so I cannot guarantee that the following is true: but in my understanding, reading code in order to get ideas does not violate copyright because only a specific expression of code (read: verbatim copy) can be copyrighted. Algorithms, code structures and APIs can be patented but not copyrighted; thus, in terms of GPL'd code, only verbatim copy & paste is a real threat. That being said, reading DOCs should be OK. Even talking about particular aspects of implementation _should_ be OK. Still, I personally prefer being over-careful and not even digging into GPL code looking for information, if I can avoid it. Code scanners like BlackDuck will find code that has been taken from somewhere else. And if Sun wanted to be malicious to other companies, taking the GPL as a weapon, they have everything they need. So again, please be careful and use good judgement. Getting RXTX GPL-infested would be a problem for us. Thanks, Martin From ajmas at sympatico.ca Wed Dec 12 20:09:40 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Dec 2007 22:09:40 -0500 Subject: [Rxtx] Help me ,please In-Reply-To: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> References: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> Message-ID: <298B975C-A04C-4516-8A61-9BE8E887B936@sympatico.ca> You need to get the latest code from CVS, since this issue has been resolved since: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code You'll want the code from the 2.1 branch. Andre On 10-Dec-07, at 07:13 , ?? wrote: > > > I used a common-user in the MAC OS 10.5. When i used rxtx 21.7 to > open the serial port on the MAC OS 10.5.the rxtx has a error. > how can I do ? thanks > > description: > error testing lock file creation error details:permission > deniedcheck_lock_status:no perminssion to create lock file. > please see: how can I use lock files with rxtx ? in install > > > ?????????? ?????????????? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Wed Dec 12 20:12:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Dec 2007 22:12:30 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? In-Reply-To: <475D4901.7030503@verizon.net> References: <47576BBD.1050703@verizon.net> <475D4901.7030503@verizon.net> Message-ID: <01A13D6F-BA2C-4086-B62A-3F34B613D689@sympatico.ca> On 10-Dec-07, at 09:11 , Bill Christens-Barry wrote: > Andre, > > Thanks for this. I'm not on top of using cvs, but I was able to > follow the instructions on the CVS page of the rxtx site to get the > code (via "cvs checkout rxtx-devel"). Is this the right branch? Not > having read any readmes etc. that may be in the project, I'm not > sure now how I go about doing a build - are there any special tools > I need for this to run on a MacBook Pro Core2Duo intel? I have the > usual developer tools, but am unsure about various libraries that > may be needed. > > Incidentally, I was able to get the version I mentioned in my list > posting by creating a lock folder. I'm not sure what repercussions > this may have, so I'm Hi, Instruction for getting from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and building on MacOS X: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Let me know if they help. Andre From fabioanjos at gmail.com Thu Dec 13 04:25:38 2007 From: fabioanjos at gmail.com (=?ISO-8859-1?Q?F=E1bio_Cristiano_dos_Anjos?=) Date: Thu, 13 Dec 2007 09:25:38 -0200 Subject: [Rxtx] Building RXTX in Windows Message-ID: <29788b250712130325r24e31afeu54a2f4eb72af612c@mail.gmail.com> Hi, I checked out RXTX from cvs, and then I tried to build it for Windows following the instructions in http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows. Are those procedures updated? I tried firts with MinGW, then the folowing errors ocurred: C:\dev\workspace\rxtx-devel\build>make MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. Error makefile 95: No match found for wildcard '/*.java)' Error makefile 95: No match found for wildcard '/*.c)' Error makefile 95: No match found for wildcard '/*.cc)' *** 3 errors during make *** Then I tried with lcc: C:\dev\workspace\rxtx-devel\src>make -f ..\Makefile.lcc MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. lcc -I\JDK\INCLUDE -I\jdk\include\win32 -I. SerialImp.c cpp: c:\dev\workspace\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could no t find include file Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skippi ng `*' `,' `jclass' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extran eous old-style parameter list Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefi nition of 'JNICALL' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previo us definition of 'JNICALL' here Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skippi ng `*' `,' `jobject' `,' `jstring' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extran eous old-style parameter list Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skippi ng `*' `,' `jobject' `,' `jint' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extran eous old-style parameter list Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too ma ny errors ** error 1 ** deleting SerialImp.obj Any help apreciated! -- F?bio Cristiano dos Anjos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071213/f0befaa2/attachment.html From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0012.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0010.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0010.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0009.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0007.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment-0007.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From ajmas at sympatico.ca Sat Dec 8 08:13:26 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 8 Dec 2007 10:13:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> On 7-Dec-07, at 14:26 , Beat Arnet wrote: > > On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. > > > Well, that's certainly what you get when electrical engineers like > me write software ;) > > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > > > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. If you can you should assign the responsibility of closing the port to the one handling the port. The other thread should simply be telling the handling thread that it should close the port. Threads are like people, in that if you give them conflicting instructions all hell breaks loose. For example of what I think you should do: class MyClass { private boolean continueReading = true; public void run() { InputStream in = null; try { in = createMyInputStream(); // or however int len = 0; byte[] buffer = new byte[1024]; while ( (len = in.read(buffer)) > 0 && continueReading ) { // handle the read data } } catch ( IOException ex ) { } finally { if ( in != null ) { in.close(); } } } } Andre From netbeans at gatworks.com Sat Dec 8 16:25:43 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 08 Dec 2007 18:25:43 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: <475B27F7.5040500@gatworks.com> >> But I am not talking about multiple threads reading from the same >> port. I am dealing with a case in which one thread is reading from the >> port, and another wants to close the port. > So I looked at the RXTX code ( close(), read() ) ( is that what u were trying to point out ? ) and it seems that a close() may not close. If there is heavy reading, then maybe close wont happen at all. Not sure why read is synchronized. If someone wants to read - uncoordinated, then that his option! But the read() and the close() does not appear to have a strong method of synchronization ( close should set a flag, that would cause any further I/O requests to throw an exception ). On would think that a close() would also prevent any further write() operations. But it does not. It also does not appear to wait for the write( b[] ) to complete ( in case the array has to be written out in chunks bec the kernel buffer is full. ) Does this help any? :-} From vorobyev.a at gmail.com Sun Dec 9 01:31:05 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Sun, 09 Dec 2007 11:31:05 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475BA7C9.6090900@gmail.com> Good day. Following problem: Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Java 6 - 1.6.02 OS OpenSuse 10.3, 2.6.22.13-0.3-default I have attach USB printer: Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device found, idVendor=088c, idProduct=2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Product: TTP 2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Manufacturer: Swecoin AB Dec 8 09:25:46 linux-fceg kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x088C pid 0x2030 Dec 8 09:25:46 linux-fceg kernel: usbcore: registered new interface driver usblp Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver linux-fceg:/var/log # ll /dev/usb* lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 Example: Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { CommPortIdentifier portIdentifier = (CommPortIdentifier) portEnum.nextElement(); System.out.println(portIdentifier.getName() + " - " + getPortTypeName(portIdentifier.getPortType())); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial Virtual LPT port not found... Parallel port /dev/lp0 not foud also. After that i modified source RXTXCommDriver.java, registerScannedPorts if (osName.equals("Linux") { String[] temp = { "lp", // linux printer port "usblp" <====================== add this }; CandidatePortPrefixes = temp; } else if (osName.equals("FreeBSD")) { But /dev/usblp0 not found anyway. After that i modified registerValidPorts if (osName.equals("Solaris") || osName.equals("SunOS")) { checkSolaris(PortName, PortType); } else { if (PortType==CommPortIdentifier.PORT_PARALLEL) <<<< i.e. port type is parallel - don't execute testRead CommPortIdentifier.addPortName( PortName,PortType,this); <<<< else if (testRead(PortName, PortType)) CommPortIdentifier.addPortName( PortName,PortType,this); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial /dev/usblp0 - Parallel /dev/lp0 - Parallel I think, what native testRead incorrectly defines presence of parallel port. I think that presence parallel port can be checked up so: int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) // port is not exist or it is not parallel port else // port is parallel! After that i execute program: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 5000); String str = "12313212312313121231321231231312"; port.getOutputStream().write(str.getBytes()); port.close(); Result: RXTXCommDriver:getCommPort(/dev/usblp0,2) LPRPort:LPRPort(/dev/usblp0) Port /dev/usblp0 in use by another application gnu.io.PortInUseException: Unknown Linux Application linux-fceg:/var/log # lsof | grep /dev/usb I.e. port is not use. Similar result at use /dev/lp0 How i can use parallel ports in my program? PS: Sorry for my english :) From tjarvi at qbang.org Sun Dec 9 00:03:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 00:03:51 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: On Sat, 8 Dec 2007, U. George wrote: >>> But I am not talking about multiple threads reading from the same >>> port. I am dealing with a case in which one thread is reading from the >>> port, and another wants to close the port. >> > So I looked at the RXTX code ( close(), read() ) ( is that what u were > trying to point out ? ) and it seems that a close() may not close. If > there is heavy reading, then maybe close wont happen at all. > > Not sure why read is synchronized. If someone wants to read - > uncoordinated, then that his option! > But the read() and the close() does not appear to have a strong method > of synchronization ( close should set a flag, that would cause any > further I/O requests to throw an exception ). > > On would think that a close() would also prevent any further write() > operations. But it does not. It also does not appear to wait for the > write( b[] ) to complete ( in case the array has to be written out in > chunks bec the kernel buffer is full. ) > Hi George, The code may not look conventional because I wasnt looking at other code at the time. It does do close to what you expect. The code got there the hard way though. close sets the fd to 0 which should throw exceptions if you try IO. while( IOLocked > 0 ) should delay close while reading and writing are in progress. In write(b[]) the following code can be found (comments added): // throw exception if closed. if ( fd == 0 ) throw new IOException(); // prevent closing while writing. IOLocked++; // Ensure the event thread is not being setup. ie // open() waitForTheNativeCodeSilly(); read() has the same logic (deleting some code for clairity) if ( fd == 0 ) throw new IOException(); IOLocked++; waitForTheNativeCodeSilly(); The close(): (for clairity just the code that we care about here:) while( IOLocked > 0 ) { sleep() } removeEventListener(); nativeClose( this.name ); fd = 0; -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 03:35:47 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 05:35:47 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475BA7C9.6090900@gmail.com> References: <475BA7C9.6090900@gmail.com> Message-ID: <475BC503.7010708@gatworks.com> > > linux-fceg:/var/log # ll /dev/usb* > lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 I suppose this is your first issue i would have expected a /dev/usblp0 ->/dev/lp1 ( since most machines have a /dev/lp0 ) > > result: > /dev/ttyS2 - Serial > /dev/ttyS1 - Serial > /dev/ttyS0 - Serial > Virtual LPT port not found... Parallel port /dev/lp0 not foud also. thats bec lp0 its in /dev/usb ! > > LPRPort:LPRPort(/dev/usblp0) > Port /dev/usblp0 in use by another application > gnu.io.PortInUseException: Unknown Linux Application rxtx code: int fd = open( filename, O_RDWR | O_NONBLOCK ); rxtx appears to want to be able to open the device for reading AND writing. I suspect permission failure. 1) anyway have a symbolic pointer from /dev/usb/usblp0 to /dev/lp0 2) change permissions to be RW for you group or owner. From netbeans at gatworks.com Sun Dec 9 04:44:35 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 06:44:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <475BD523.3000900@gatworks.com> > close sets the fd to 0 which should throw exceptions if you try IO. Setting fd to 0 appears to be the last step in rxtx-close. It should be the first step, as a mutex to prevent any further I/O to the channel. With hyperthreads, quad cpu's, other threads can be simultaneously ( in real time ) executing reads & writes & other things. > > while( IOLocked > 0 ) should delay close while reading and writing are > in progress. Yes, but there is nothing there to prevent any further user I/O. You could have a bunch of threads continue to read & write, and keep IOLock > 0 for some time. Even if it did reach IOLock reached 0, there is still the possibility of some thread upping IOLock inbetween. > > In write(b[]) the following code can be found (comments added): > > // throw exception if closed. > if ( fd == 0 ) throw new IOException(); > // prevent closing while writing. Where is the "prevent further writing while closing" ? > > (for clairity just the code that we care about here:) > > while( IOLocked > 0 ) > { sleep() } this can take a long time to process. And defeats the purpose of a close() at time x. Because at time x+1, any further user requests to that file descriptor should have failed. One also has to ask why is the user program still reading or writing after having the close() called? But that is for the user to figure out. The orig question posed was to have a multi cpu, and 2 java threads. 1 thread was reading, while the other was ( attempting to ) closeing. probably something like this should be done: public close() { synchonize( eis ) { we_are_closing_up = true; while ( IOLock > 0 ) sleep( 100ms ); } native_close(); fd = 0; } we_are_closing_up = false; } public write() { if ( we_are_closing_up ) synchronize( eis ) { ; } if ( fd == 0 ) throw ( ..... IOLock++; ...... this is also not perfect. There is the possibility that a close could happen after the test, and before the IOLock++ From beat.arnet at gmail.com Sun Dec 9 05:44:23 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 09 Dec 2007 07:44:23 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475BE327.9010709@gmail.com> Thanks to all for responding to my original question! From what I hear, we now suspect that some improvements in RXTX might be necessary to make the code 100% thread safe. I would be happy to help, but I fear that I might not quite have the necessary training/skills. Maybe with some guidance I could give it a try. Since there has been no official release since 2.1.7, I am also wondering where I should start in the trunk so that I can be sure that all valid bug fixes that have been submitted sine 2.1.7 are included. However, I would also like to find out if there is something short-term that I can do in my application to avoid dead-locks on dual core machines, before RXTX is fixed. After Daniel's response, I synchronized all RXTXPort accesses, but I have still some crashes being reported from the field, albeit much less (and possibly unrelated?). Should I setup my code such that all accesses to the serial port happen in one unique thread? Would this prevent the problems that are described below? Any further guidance from the group would be appreciated. Regards, Beat U. George wrote: >> close sets the fd to 0 which should throw exceptions if you try IO. >> > Setting fd to 0 appears to be the last step in rxtx-close. It should be > the first step, as a mutex to prevent any further I/O to the channel. > With hyperthreads, quad cpu's, other threads can be simultaneously ( in > real time ) executing reads & writes & other things. > > > >> while( IOLocked > 0 ) should delay close while reading and writing are >> in progress. >> > Yes, but there is nothing there to prevent any further user I/O. You > could have a bunch of threads continue to read & write, and keep IOLock > > 0 for some time. > Even if it did reach IOLock reached 0, there is still the possibility of > some thread upping IOLock inbetween. > >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. >> > Where is the "prevent further writing while closing" ? > >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } >> > this can take a long time to process. And defeats the purpose of a > close() at time x. Because at time x+1, any further user requests to > that file descriptor should have failed. > One also has to ask why is the user program still reading or writing > after having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/6b16e64b/attachment-0006.html From tjarvi at qbang.org Sun Dec 9 11:01:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 11:01:00 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > >> close sets the fd to 0 which should throw exceptions if you try IO. > Setting fd to 0 appears to be the last step in rxtx-close. It should be the > first step, as a mutex to prevent any further I/O to the channel. With > hyperthreads, quad cpu's, other threads can be simultaneously ( in real time > ) executing reads & writes & other things. > > >> >> while( IOLocked > 0 ) should delay close while reading and writing are in >> progress. > Yes, but there is nothing there to prevent any further user I/O. You could > have a bunch of threads continue to read & write, and keep IOLock > 0 for > some time. > Even if it did reach IOLock reached 0, there is still the possibility of some > thread upping IOLock inbetween. >> >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. > Where is the "prevent further writing while closing" ? >> >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } > this can take a long time to process. And defeats the purpose of a close() at > time x. Because at time x+1, any further user requests to that file > descriptor should have failed. > One also has to ask why is the user program still reading or writing after > having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 thread > was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could happen > after the test, and before the IOLock++ > There are two questions in the back of my mind. The first is I'd like to see some form of documentation in the Java API that says this is the right behavior. Anything from file IO to network sockets. The second is that we are dealing with perhaps the slowest reads and writes out there. I'd anticipate some downstream impact (incompatability) with people using the current implementation. At least at first, a change like this should be something people opt into via preferences or other means. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 12:17:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 14:17:15 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C3F3B.9050003@gatworks.com> > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. ?? I'm not sure what behavior your are expecting the JAVA docs to explain? I'd be more interested in the OS docs that will/could explain the interaction of threads and the sequencing of I/O operations amongst active cpu instruction pipelines. > > The second is that we are dealing with perhaps the slowest reads and > writes out there. I'd anticipate some downstream impact > (incompatability) with people using the current implementation. At > least at first, a change like this should be something people opt into > via preferences or other means. u mean there are folks that continue to read & write even though they also issued a (premature) close ? I am not aware of any OS that behaves like that. Or allows that. Yes, but if you will notice, the the speed of USB devices, that are made to behave like serial, or parallel devices, are very-very fast. A 500ms sleep is forever on some USB devices. BTW: Since JAVA source went public, sorta, did java publish the commapi source? BTW#2:Your mail to 'Rxtx' with the subject If not DEBUGing, remove useless calls to report() et al Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 46243 bytes with a limit of 40 KB From netbeans at gatworks.com Sun Dec 9 13:00:09 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 15:00:09 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C4949.5060109@gatworks.com> > > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. from Class CommPort: After a communications port has been identified and opened it can be configured with the methods in the low-level classes like SerialPort and ParallelPort. Then an IO stream can be opend for reading and writing data. Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown. From dwippermann at gmx.net Sun Dec 9 13:36:28 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:36:28 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: Hi all, > If you can you should assign the responsibility of closing the port > to the one > handling the port. The other thread should simply be telling the > handling thread > that it should close the port. Threads are like people, in that if > you give them > conflicting instructions all hell breaks loose. For example of what > I think you > should do: > yes, that you be the common way if I had full control over the thread. But the thread is implemented and started by RXTX, I only get event through my listener. How should the listener be able to close the port if no event is triggered? Can I wake up the RXTX thread to send a dummy event to trigger the close from inside the listener? Daniel From dwippermann at gmx.net Sun Dec 9 13:55:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:55:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: And hi once more, > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ Thats the reason why I encapsulated all access in synchronized blocks using one mutex. You simply have no problem with "after ... , but before..." anymore :) One other problem I see is the use of the ++/-- operators on a variable that can be accessed by mutliple threads in parallel. I'll run a short test tomorrow on my office machine, but I assume that its read-modify-write behaviour might bring up a collision like: IOLocked = 100, both thread are running in different CPUs, but due to timing arrive at the "IOLocked--" nearly simultaneously CPU 1: reads variable to register => register = 100 CPU 2: doing something else -- CPU 1: decrements register => register = 99 CPU 2: reads variable to register => register = 100 -- CPU 1: writes register to variable => variable = 99 CPU 2: decrements register => register = 99 -- CPU 1: doing something else CPU 2: writes register to variable => variable = 99 It should have decremented twice, but it didn't... Thats a common situtation where locking is needed: modify the same variable from different threads without synchonization is hell :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/4bd9d474/attachment-0005.html From netbeans at gatworks.com Thu Dec 6 04:14:53 2007 From: netbeans at gatworks.com (U. George) Date: Thu, 06 Dec 2007 06:14:53 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al Message-ID: <4757D9AD.2080305@gatworks.com> For the most part the report() calls from everywhere is usefull in debugging whats happening within rxtx. BUT if you are not debugging, then it is just wasted CPU cycles. That also includes the sprintf's sprinkled here and there. I placed the DEBUG code ( SerialImp.c ) under the #ifdef DEBUG . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071206/92c448eb/attachment-0005.pl From tjarvi at qbang.org Sun Dec 9 19:15:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:15:44 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <4757D9AD.2080305@gatworks.com> References: <4757D9AD.2080305@gatworks.com> Message-ID: This looks OK to me George. Just two issues. make_message is probably copyrighted by the Free Software Foundation. It is probably easier to recode it than deal with the minor potential issues. The only other minor issue is that commenting out code isn't really better than deleting it in the long run. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 19:35:41 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 21:35:41 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> Message-ID: <475CA5FD.6050801@gatworks.com> Trent Jarvi wrote: > > This looks OK to me George. Just two issues. > > make_message is probably copyrighted by the Free Software Foundation. > It is probably easier to recode it than deal with the minor potential > issues. code u refer to is not used. I'm not too sure if "all" cc/libs can handle the particular var-args scheme. So if blows up, then that becomes an issue, but not harmfull for anybody's run. I did want to use it to do: REPORT("FIONREAD failed with error %s\n", strerror( errno )); or more recently REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); Since u PORT this to other machines, its not clear if var-args works everywhere the same way. u got any notion? > > The only other minor issue is that commenting out code isn't really > better than deleting it in the long run. > Sorta, sorta not. For short run ( in the heading of small changes ) it looks just like all the other items (historically) commented out, but not yet removed :) More things to clean up for the long run i guess. From tjarvi at qbang.org Sun Dec 9 19:47:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:47:37 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <475CA5FD.6050801@gatworks.com> References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> >> This looks OK to me George. Just two issues. >> >> make_message is probably copyrighted by the Free Software Foundation. It >> is probably easier to recode it than deal with the minor potential issues. > code u refer to is not used. I'm not too sure if "all" cc/libs can handle the > particular var-args scheme. So if blows up, then that becomes an issue, but > not harmfull for anybody's run. > > I did want to use it to do: > REPORT("FIONREAD failed with error %s\n", strerror( errno )); > > or more recently > > REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); > > Since u PORT this to other machines, its not clear if var-args works > everywhere the same way. u got any notion? > >> >> The only other minor issue is that commenting out code isn't really better >> than deleting it in the long run. >> > Sorta, sorta not. For short run ( in the heading of small changes ) it looks > just like all the other items (historically) commented out, but not yet > removed :) More things to clean up for the long run i guess. > So far as I know, var-args works fine on the other platforms. See ioctl in termios.c (w32) for instance. I would rather link to make_message or implement a work alike. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 20:49:44 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 22:49:44 -0500 Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: References: Message-ID: <475CB758.6000508@gatworks.com> rxtx-bounces at qbang.org wrote: > Your mail to 'Rxtx' with the subject > > Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al > > Is being held until the list moderator can review it for approval. I suppose this limitation was a recent change? :/ From tjarvi at qbang.org Sun Dec 9 20:55:33 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 20:55:33 -0700 (MST) Subject: [Rxtx] Your message to Rxtx awaits moderator approval In-Reply-To: <475CB758.6000508@gatworks.com> References: <475CB758.6000508@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > > rxtx-bounces at qbang.org wrote: >> Your mail to 'Rxtx' with the subject >> >> Re: [Rxtx] If not DEBUGing, remove useless calls to report() et al >> >> Is being held until the list moderator can review it for approval. > > > I suppose this limitation was a recent change? :/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > No. It is just a size limititation. I have upped it in the past. You might consider sending it as a .gz/.zip. Many people end up with full mailboxes and then bounce. The size limitation is 3 years old. The reason I don't get to the deffered email very often is it gets about 1k spams a week. At least we keep the spam out of everyones email box. If you like, I can fish out your email. I'd suggest zipping it though. There are ~500 people on the list but most just want to follow along. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 21:07:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 23:07:15 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> <475CA5FD.6050801@gatworks.com> Message-ID: <475CBB73.9080805@gatworks.com> > So far as I know, var-args works fine on the other platforms. See ioctl > in termios.c (w32) for instance. > dont have a win32 development system. At least not a recent one. And not installed anywhere :}} > I would rather link to make_message or implement a work alike. Its not a problem. looks almost like the jprint( ... ). -------------- next part -------------- A non-text attachment was scrubbed... Name: IfDef_patch.gz Type: application/x-gzip Size: 10381 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/5a6ec2c1/attachment-0005.gz From vorobyev.a at gmail.com Mon Dec 10 00:41:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 10:41:32 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475CEDAC.9090907@gmail.com> >2) change permissions to be RW for you group or owner. Thanks, it is my stupid mistake. But usb printer not work anyway. Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; ========================================== test program in c++: void ParallelPort::test(){ int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) return ; printf("status: 0x%02x\n",status); printf("Busy (~status & LP_PBUSY) : %x\n", (~status & LP_PBUSY)); printf("Error (~status & LP_PERRORP): %x\n", (~status & LP_PERRORP)); printf("Select (status & LP_PSELECD) : %x\n", (status & LP_PSELECD)); printf("Paper out (status & LP_POUTPA) : %x\n", (status & LP_POUTPA)); } result: status: 0x18 Busy (~status & LP_PBUSY) : 80 Error (~status & LP_PERRORP): 0 Select (status & LP_PSELECD) : 10 Paper out (status & LP_POUTPA) : 0 ParallelPort port("/dev/usblp0"); port.open(); port.write("Hello world"); port.write(0x1e); // cut port.close(); Result: Device print data and cut paper. ========================================== test program in java: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 50000); System.out.println("paper out: "+ port.isPaperOut()); System.out.println("buzy: "+ port.isPrinterBusy()); System.out.println("error: "+ port.isPrinterError()); System.out.println("select: "+ port.isPrinterSelected()); System.out.println("timeout: "+ port.isPrinterTimedOut()); result: paper out: true buzy: false error: false select: false timeout: false From netbeans at gatworks.com Sun Dec 9 22:04:46 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 00:04:46 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475CEDAC.9090907@gmail.com> References: <475CEDAC.9090907@gmail.com> Message-ID: <475CC8EE.9040205@gatworks.com> Alexander Vorobyev wrote: >> 2) change permissions to be RW for you group or owner. > Thanks, it is my stupid mistake. > > But usb printer not work anyway. > Similar problem in that that the status of port is defined incorrectly (probably usblp.c driver) and the library throw IOException; I suppose the USB/LP driver may not be sophisticated enough to provide that information, presuming that information is at all relevant to the device itself ( like a parallel port Zip Drive ). From vorobyev.a at gmail.com Mon Dec 10 01:46:32 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 10 Dec 2007 11:46:32 +0300 Subject: [Rxtx] One more question about usb->lpt Message-ID: <475CFCE8.3080807@gmail.com> Good day I wrote about the arisen problems at work with the device/dev/usb/lp0. At use c ++ work with the given device is made easily enough. Example void Usb2Lpt::open(){ handle = ::open(this->device.c_str(),O_RDWR|O_NOCTTY|O_NDELAY); if (handle<0) throw FileNotOpenException(strerror(errno)); } void Usb2Lpt::close(){ ::close(handle); handle = -1; } void Usb2Lpt::waitForRead(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, &rfds, NULL, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } void Usb2Lpt::waitForWrite(){ fd_set rfds; struct timeval tv; //------------------------------------------- if (mode==NON_BLOCK) return; //------------------------------------------- FD_ZERO(&rfds); FD_SET(handle, &rfds); tv.tv_sec = timeout/1000; tv.tv_usec = (timeout-tv.tv_sec*1000)*1000; //------------------------------------------- switch(select(handle+1, NULL, &rfds, NULL, &tv)){ case -1:{ throw IOException(std::string("select(handle+1, NULL, &rfds, NULL, &tv) failed.. Error: ")+strerror(errno)); break; } case 0:{ throw IOException("Timeout"); break; } default:{ break; } }; } unsigned char* Usb2Lpt::read(uint size){ .... r = ::read(handle,buf,len); ... return buf; } int Usb2Lpt::write(char data){ int w; waitForWrite(); w = ::write(handle,&data,sizeof(data)); if (w==-1){ if (errno==EAGAIN) return 0; else throw IOException(strerror(errno); } return w; } I.e. it is work as write/read + blocking/nonblocking mode; It is how much easy to make support of such driver in library rxtx? From zhouzhao58 at 163.com Mon Dec 10 05:13:14 2007 From: zhouzhao58 at 163.com (=?GBK?B?1tzuyA==?=) Date: Mon, 10 Dec 2007 20:13:14 +0800 (CST) Subject: [Rxtx] Help me ,please Message-ID: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> I used a common-user in the MAC OS 10.5. When i used rxtx 2.1.7 to open the serial port on the MAC OS 10.5.the rxtx has a error. how can I do ? thanks description: error testing lock file creation error details:permission deniedcheck_lock_status:no perminssion to create lock file. please see: how can I use lock files with rxtx ? in install -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/0ebc8026/attachment-0005.html From dwippermann at gmx.net Mon Dec 10 05:29:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 13:29:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Hi again, > One other problem I see is the use of the ++/-- operators on a > variable that can be accessed by mutliple threads in parallel. I'll > run a short test tomorrow on my office machine, but I assume that > its read-modify-write behaviour might bring up a collision like: > > IOLocked = 100, both thread are running in different CPUs, but due > to timing arrive at the "IOLocked--" nearly simultaneously > > CPU 1: reads variable to register => register = 100 > CPU 2: doing something else > -- > CPU 1: decrements register => register = 99 > CPU 2: reads variable to register => register = 100 > -- > CPU 1: writes register to variable => variable = 99 > CPU 2: decrements register => register = 99 > -- > CPU 1: doing something else > CPU 2: writes register to variable => variable = 99 > > It should have decremented twice, but it didn't... Thats a common > situtation where locking is needed: modify the same variable from > different threads without synchonization is hell :) Small sample app: (((snip))) public class Main { static Object mutex; static int counter; public static void concurrencyTest(final boolean useMutex) { Runnable r = new Runnable() { public void run() { synchronized(mutex) { try { mutex.wait(); } catch (Exception ex) { ex.printStackTrace(); } } for (int i = 0; i < 1000000; i++) { if (useMutex) { synchronized (mutex) { counter++; } } else { counter++; } } } }; try { counter = 0; mutex = new Object(); Thread t1 = new Thread(r); Thread t2 = new Thread(r); // start the two threads, they will wait for the mutex to be signaled t1.start(); t2.start(); // just a little sleep before the work Thread.sleep(100); synchronized (mutex) { // signal the two threads to start working mutex.notifyAll(); } t1.join(); t2.join(); System.out.println("useMutex = " + useMutex + " => counter = " + counter); } catch (Exception ex) { ex.printStackTrace(); } } public static void main(String[] args) { concurrencyTest(true); concurrencyTest(false); } } (((snip))) The program starts two threads. Each thread should increment a counter 1 million times, hence you expect a result of 2 million. Haven't tested it on a single-core machine, but on my multi-core office machine I get: useMutex = true => counter = 2000000 useMutex = false => counter = 1221835 The second result is fluctuating heavily. By that example I want to demonstrate that the use of "IOLocked++" for locking purposes is by far not thread-safe. And if you have heavy trafiic over the serial port (as I have, up to 2,8 MB of data to transceive at 115kbps), the chance of synchronization issues is reasonable. The only possibility I have to counter this at the moment is to synchronize all function calls to RXTX, especially close(), getInputStream(), read() as well as getOutputStream() and write(). It cannot be taken as a general advise to solve this problem, because synchronization has to fit into thr rest of your app. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/99aca116/attachment-0005.html From netbeans at gatworks.com Mon Dec 10 06:59:29 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 08:59:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D4641.7050001@gatworks.com> > By that example I want to demonstrate that the use of "IOLocked++" for > locking purposes is by far not thread-safe. And if you have heavy > trafiic over the serial port (as I have, up to 2,8 MB of data to > transceive at 115kbps), the chance of synchronization issues is reasonable. Synchronization of read/writes should be handled by the user. There is nothing in rxtx that will disturb the synchronization, as it is not an rxtx function. If a user wants to have 3 threads writing to that device, its up to the user to coordinate the proper sequencing of writes. The synchronize reads in SerialImp/read() appear to be a violation of the abstract class InputStream. If you want 3 threads simultaneously reading from that device, then thats up to the users application to determine the sequence for access. The IOLocked is a flag to indicate that a read/write I/O operation is in progress. it does not lockout the other from happening simultaneously. The synchronize read() does prevent simultaneous reads from multiple threads. The IOLocked indicator does prevent the close() from starting up, as close() waits for the IOLock value to become 0. The presumption is that the application's reads/writes will cease because the application has issued a close(). You wouldnt issue any further I/O after the close - would you? From dwippermann at gmx.net Mon Dec 10 07:53:03 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 15:53:03 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi all, > The IOLocked is a flag to indicate that a read/write I/O operation > is in > progress. it does not lockout the other from happening simultaneously. > The synchronize read() does prevent simultaneous reads from multiple > threads. > The IOLocked indicator does prevent the close() from starting up, as > close() waits for the IOLock value to become 0. The presumption is > that > the application's reads/writes will cease because the application has > issued a close(). You wouldnt issue any further I/O after the close - > would you? You are completely right, I never meant to imply something different. The IOLocked shall not lock concurrent reads or concurrents writes away, but be a signal for the close method that some read or write is still underway and it has to wait for them to finish. But the original question was, why the IOLocked variable has a value ! = 0 ALTHOUGH all read and write activities have ceased quite a while ago? And there were only two threads involved: on one side the thread that called open() and write() and on the other side the RXTX monitor thread that calling read(). No multiple reads or writes! Only a parallel write while reading. But that cannot be forbidden since we talk about an USART. Or am I wrong? Is there a problem to to have one read() and one write() run simulatenously? If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/db7e990f/attachment-0004.html From netbeans at gatworks.com Mon Dec 10 10:17:26 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 12:17:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <475D74A6.4000209@gatworks.com> > If that case is an allowed one, IOLocked has to be synchronized because it is altered in read() and write(). i suppose u mean that the IOLocked++, and the IOLocked-- has to be accomplished atomically ? I suppose besides meaning that you would also like that? :} From dwippermann at gmx.net Mon Dec 10 10:22:40 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:22:40 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: Hi everone, > Hi all, >> The IOLocked is a flag to indicate that a read/write I/O operation >> is in >> progress. it does not lockout the other from happening >> simultaneously. >> The synchronize read() does prevent simultaneous reads from multiple >> threads. >> The IOLocked indicator does prevent the close() from starting up, as >> close() waits for the IOLock value to become 0. The presumption is >> that >> the application's reads/writes will cease because the application has >> issued a close(). You wouldnt issue any further I/O after the close - >> would you? > You are completely right, I never meant to imply something > different. The IOLocked shall not lock concurrent reads or > concurrents writes away, but be a signal for the close method that > some read or write is still underway and it has to wait for them to > finish. > But the original question was, why the IOLocked variable has a > value != 0 ALTHOUGH all read and write activities have ceased quite > a while ago? And there were only two threads involved: on one side > the thread that called open() and write() and on the other side the > RXTX monitor thread that calling read(). No multiple reads or > writes! Only a parallel write while reading. But that cannot be > forbidden since we talk about an USART. Or am I wrong? Is there a > problem to to have one read() and one write() run simulatenously? > If that case is an allowed one, IOLocked has to be synchronized > because it is altered in read() and write(). I've prepared a patch to RXTXPort.java to help me outline my point of view in this discussion. It's attached to this posting. In general, three things have been done: 1) A new variable "IOLockedMutex" is introduced. It's only purpose is to be passed as a parameter to the synchronized statement. 2) Every "IOLocked++" is encapsulated by that said synchronized block 3) In some methods there were multiple "IOLocked--". Those have all been substituted by a one synchronized "IOLocked--" which is processed in a "finally" statement that handles all exceptions from right after "IOLocked++" till the end of the method. So every occurence or variation of the sequence: > IOLocked++; > waitForTheNativeCodeSilly(); > try { > // something method specific here > } catch (IOException ex) { > IOLocked--; > throw ex; > } > IOLocked--; has been replaced by: > synchronized (IOLockedMutex) { > IOLocked++; > } > try { > waitForTheNativeCodeSilly(); > // something method specific here > } finally { > synchronized (IOLockedMutex) { > IOLocked--; > } > } In my opinion that chance has no impact on the surrounding application. It wont block away one function call if another one is running, it only ensures, that only one thread alters the IOLocked variable at any given time. So you could have one polling read() and one write() action in parallel without interference. In the hope, that I haven't abused your patience too much :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0008.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RXTXPort_IOLockedMutex.diff Type: application/octet-stream Size: 6297 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0004.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/100c8240/attachment-0009.html From dwippermann at gmx.net Mon Dec 10 10:44:17 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 18:44:17 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> Message-ID: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Hi! > i suppose u mean that the IOLocked++, and the IOLocked-- has to be > accomplished atomically ? > > I suppose besides meaning that you would also like that? :} Yes, indeed... I was lacking the word "atomically", but at least you were able to follow my remaining semi-english explanation :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/5f88033d/attachment-0004.html From netbeans at gatworks.com Mon Dec 10 14:03:38 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 16:03:38 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DA9AA.90106@gatworks.com> According to this (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): > A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking. It appears that "volatile" makes concurrent updates atomic. Its not intuitive. So is it true ? Daniel Wippermann wrote: > Hi! > >> i suppose u mean that the IOLocked++, and the IOLocked-- has to be >> accomplished atomically ? >> >> I suppose besides meaning that you would also like that? :} > Yes, indeed... I was lacking the word "atomically", but at least you > were able to follow my remaining semi-english explanation :) > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From dwippermann at gmx.net Mon Dec 10 14:33:02 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Mon, 10 Dec 2007 22:33:02 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: Hi, > According to this > (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html > ): > > A write to a volatile field happens-before every subsequent read > of that same field. Writes and reads of volatile fields have similar > memory consistency effects as entering and exiting monitors, but do > not entail mutual exclusion locking. > > It appears that "volatile" makes concurrent updates atomic. Its not > intuitive. So is it true ? > I tried the volatile declaration on my small ConcurrencyTest app. It has no effect, the unsynchronized version still misses a vast amount of increments. I think that the read-modify-write behaviour of "++" and "--" is not covered by the "happens-before" clause of the volatile declaration. It only ensures, that the corresponding read and write operations are not interrupted, the time in between these operations is not covered. Although it sounded promising on the first look... I can't imagine a different working approach to get IOLocked thread- safe at the moment. But perhaps I'm stuck and just have to think about it another night or two... Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071210/d13a0db5/attachment-0004.html From netbeans at gatworks.com Mon Dec 10 15:32:42 2007 From: netbeans at gatworks.com (U. George) Date: Mon, 10 Dec 2007 17:32:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <475DBE8A.8050408@gatworks.com> I suspect that what they said is not exact. My impression, at one time, was that the volatile object could not be optimized into not writing to memory. Oh well. Have you tried java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? from jdk1.5 and beyond? these set of utilities have an interesting way of 'atomically' incrementing the variable. I'd be curious if your test would also fail using these utilities. Daniel Wippermann wrote: > Hi, > >> According to this >> (http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html): >> >/ A write to a volatile field happens-before every subsequent read of >> that same field. Writes and reads of volatile fields have similar >> memory consistency effects as entering and exiting monitors, but do >> not entail mutual exclusion locking. / It appears that "volatile" >> makes concurrent updates atomic. Its not intuitive. So is it true ? > > > I tried the volatile declaration on my small ConcurrencyTest app. It has > no effect, the unsynchronized version still misses a vast amount of > increments. > > I think that the read-modify-write behaviour of "++" and "--" is not > covered by the "happens-before" clause of the volatile declaration. It > only ensures, that the corresponding read and write operations are not > interrupted, the time in between these operations is not covered. > Although it sounded promising on the first look... > > I can't imagine a different working approach to get IOLocked thread-safe > at the moment. But perhaps I'm stuck and just have to think about it > another night or two... > > Daniel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com.cn Mon Dec 10 19:22:23 2007 From: zhanglong at adventnet.com.cn (zl) Date: Tue, 11 Dec 2007 10:22:23 +0800 Subject: [Rxtx] Homestay 2008 Beijing Olympic Message-ID: <475DF45F.5030702@adventnet.com.cn> Do you want to come to Beijing for 2008 Olympic? Please choose homestay for your accommodation and select my home. Introduction: The whole apartment is furnished in traditional Chinese Style. All furniture is brand new. There are two bedrooms, a modern kitchen, a living room, one bathrooms and one storageroom. It has all the gadgets and amenities including ADSL internet connection, on-demand cable, washer, fridge, microwave, a 25 inch television set, home security system.And community body guard is also included. 24 hours hot water services, local banking facilities,air conditioners are available. Everything is comfortable for living, also supermarket(Carrefour is 5 minuters), park, school, restaurants, entertainment places is surrounding. It's about 10 minutes' drive to the National Stadium (the Bird Nest), and no longer than 5 minutes' walk to the Olympics Forest Park. The subway line 13 and 5 's station of Lishuiqiao is 5-10 minutes' walking distance. For more detail and pictures,Please look at: http://picasaweb.google.com/zlong6688/HomestayBeijing2008 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249599243132994 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096249629307904114 http://picasaweb.google.com/zlong6688/HomestayBeijing2008/photo?authkey=pI8IGdSnAqM#5096615126729827426 Contact me: E-mail: zhanglong at adventnet.com.cn Mobile: 13241969320 MSN:zlong6666 at hotmail.com PS: Please help me tell this message to your friends. And you can post this message with no limit. (End) ------------------------------------------------- From dwippermann at gmx.net Mon Dec 10 22:02:59 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 06:02:59 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> Message-ID: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Hi, > I suspect that what they said is not exact. My impression, at one > time, > was that the volatile object could not be optimized into not writing > to > memory. Oh well. > > Have you tried > java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? > from jdk1.5 and beyond? > > these set of utilities have an interesting way of 'atomically' > incrementing the variable. I'd be curious if your test would also fail > using these utilities. thanks for that hint, an interesting package :) This class works as expected and is way faster (at least on my machine) that synchronizing the increment manually. The only drawback - as you mentioned before - is that it requires Java5 to run... And as far as I understand, RXTX targets 1.3 and later JREs... But an eyecatcher indeed, thanks again. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/376692e5/attachment-0004.html From netbeans at gatworks.com Tue Dec 11 05:28:29 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 07:28:29 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Message-ID: <475E826D.40609@gatworks.com> u didnt catch it all. although introduced in 1.5, those same folks ( not sun ) who made that stuff public domain, also created a 1.4 version, and a 1.3 version. Those backward compatable routines are 'synchronize'd, so should run no better that what rxtx is currently doing. BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx synchronize directives be completely removed from reads and writes ( as well as the removal of IOLocked et al ) ? Daniel Wippermann wrote: > Hi, > >> I suspect that what they said is not exact. My impression, at one time, >> was that the volatile object could not be optimized into not writing to >> memory. Oh well. >> >> Have you tried >> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? >> from jdk1.5 and beyond? >> >> these set of utilities have an interesting way of 'atomically' >> incrementing the variable. I'd be curious if your test would also fail >> using these utilities. > > thanks for that hint, an interesting package :) > > This class works as expected and is way faster (at least on my machine) > that synchronizing the increment manually. > > The only drawback - as you mentioned before - is that it requires Java5 > to run... And as far as I understand, RXTX targets 1.3 and later JREs... > > But an eyecatcher indeed, thanks again. > > Daniel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Tue Dec 11 08:48:41 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Tue, 11 Dec 2007 10:48:41 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475E826D.40609@gatworks.com> References: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <475E826D.40609@gatworks.com> Message-ID: I confirmed Daniel's theory by running his example on both a dual-core and single-core machine. Both counter results are identical on a single core machine, and differ on dual cores. I then tried the synchronized and concurrent.atomic approach and noticed that they both make RXTXPort unbearably slow. Thanks for all your help! Beat On Dec 11, 2007 7:28 AM, U. George wrote: > u didnt catch it all. although introduced in 1.5, those same folks ( not > sun ) who made that stuff public domain, also created a 1.4 version, and > a 1.3 version. Those backward compatable routines are 'synchronize'd, so > should run no better that what rxtx is currently doing. > > > BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx > synchronize directives be completely removed from reads and writes ( as > well as the removal of IOLocked et al ) ? > > Daniel Wippermann wrote: > > Hi, > > > >> I suspect that what they said is not exact. My impression, at one time, > >> was that the volatile object could not be optimized into not writing to > >> memory. Oh well. > >> > >> Have you tried > >> java.util.concurrent.atomic.AtomicInteger.getAndIncrement() ? > >> from jdk1.5 and beyond? > >> > >> these set of utilities have an interesting way of 'atomically' > >> incrementing the variable. I'd be curious if your test would also fail > >> using these utilities. > > > > thanks for that hint, an interesting package :) > > > > This class works as expected and is way faster (at least on my machine) > > that synchronizing the increment manually. > > > > The only drawback - as you mentioned before - is that it requires Java5 > > to run... And as far as I understand, RXTX targets 1.3 and later JREs... > > > > But an eyecatcher indeed, thanks again. > > > > Daniel > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/356ff730/attachment-0003.html From dwippermann at gmx.net Tue Dec 11 08:50:07 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 16:50:07 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> Message-ID: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Hi all, > Those backward compatable routines are 'synchronize'd, so > should run no better that what rxtx is currently doing. Why do you think so? All write() methods in the SerialOutputStream class are not synchronized at all at the moment. And the "synchronized" read() methods only forbid to call more than one of them at any given time because they lock the SerialInputStream object they are living in. But they have no locking influence on a concurrent write() and its altering of IOLocked. So rxtx would do much better than what it is currently doing. > BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx > synchronize directives be completely removed from reads and writes > ( as > well as the removal of IOLocked et al ) ? That's not my decision to make, it's more a political question whether the library takes care of it or the end user developer. You can of course remove it all and let the user take care of it... If you ask me personally: I believe it makes perfect sense to do it in the library. The speed impact is marginal. But it touches the integrity of the library state (since IOLocked cannot be influenced directly from outside). If you cannot close the port because an internal variable's content is damaged, that is nothing to be handled by the end user dev. From my point of view it's the library's responsibility. But I'm tired of "defending" my position here. If you think, it is ok how it is done at the moment: fine, let's end that discussion here. That's the advantage of open source and an open mind: just branch, patch and continue :) On a small side note I'd like to thank Trent, Martin and all the other contributors of this project. It's damn good lib and saved me a lot of time in the past. Keep up the good work, guys! Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/78331b1d/attachment-0003.html From Steffen.DETTMER at ingenico.com Tue Dec 11 09:26:30 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 11 Dec 2007 17:26:30 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <20071211162630.GI2253@elberon.bln.de.ingenico.com> * Daniel Wippermann wrote on Tue, Dec 11, 2007 at 16:50 +0100: > > BTW: wouldnt all run a whole lot better ( faster anyway ) if > > the rxtx synchronize directives be completely removed from > > reads and writes ( as well as the removal of IOLocked et al) ? > > If you ask me personally: I believe it makes perfect sense to > do it in the library. The speed impact is marginal. But it > touches the integrity of the library state (since IOLocked > cannot be influenced directly from outside). I agree. The alternative would be to require that each using application needs to serialise any call to lib functions. In Java usually multiple threads are very common, so I think its likely that all applications would need to add some locking around. I'm afraid it would be uncomfortable, difficult and `risky' to use then (and if not locked correctly, strange behavior could happen later on, after tests, and so on... personally I really hate such problems because they are hard to find, so best is to avoid them I think :)). So I think, having (or keeping, with some extensions / fixes) this `threadsafety' as a lib feature keeps rxtx easily usable and everyone would benefit :) > On a small side note I'd like to thank Trent, Martin and all > the other contributors of this project. It's damn good lib and > saved me a lot of time in the past. Keep up the good work, > guys! well said, again I agree! :) Yes, thanks a lot guys!! oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Martin.Oberhuber at windriver.com Tue Dec 11 09:40:45 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 17:40:45 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net><6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net><695CE8C6-D794-464A-9550-150C1501A09F@gmx.net><475E826D.40609@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B0F@ism-mail03.corp.ad.wrs.com> Hi all, I haven't had time to follow this thread in too much detail, but Daniel's argument as well as his patch make perfectly sense to me. The modifications he made seem to be required to ensure data integrity in a multi-threaded enviroment, and his methods (add an additional mutex, use try...finally) seem perfectly right to me: ensuring data integrity, without changing any other semantics of the existing implementation (especially read/write concurrency on a higher level). I also agree that data integrity needs to be maintained at the library level, and not offloaded to the client by not using synchronized at all. I can't understand why these modifications should make RXTXPort a lot slower. On modern JVM's, the "synchronized" statement is processed real fast. Beat can you give more background about your measurements? Daniel: thanks for your contributions and your perseverance. Please don't give up and create your own branch of RXTX. We need guys like you in our Open Source Community :-) Thanks Martin ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Beat Arnet Sent: Tuesday, December 11, 2007 4:49 PM To: U. George Cc: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem I confirmed Daniel's theory by running his example on both a dual-core and single-core machine. Both counter results are identical on a single core machine, and differ on dual cores. I then tried the synchronized and concurrent.atomic approach and noticed that they both make RXTXPort unbearably slow. Thanks for all your help! Beat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/6333f1fa/attachment-0003.html From netbeans at gatworks.com Tue Dec 11 09:44:24 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 11:44:24 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <475EBE68.8030606@gatworks.com> Daniel Wippermann wrote: > Hi all, > >> Those backward compatable routines are 'synchronize'd, so >> should run no better that what rxtx is currently doing. > > Why do you think so? All write() methods in the SerialOutputStream class > are not synchronized at all at the moment. And the "synchronized" read() > methods only forbid to call more than one of them at any given time > because they lock the SerialInputStream object they are living in. But > they have no locking influence on a concurrent write() and its altering > of IOLocked. So rxtx would do much better than what it is currently doing. Because, if you were to use the (AtomicInteger) IOLocked.getAndIncrement(); u would get a hotspot/native operation in JDK1.5 and JDK1.6, but with jdk1.3 & 1.4, with the backward compatible routines, you would get the synchronise'd routine for getAndIncrement. the JDK1.3 backward routine would be just as good as your suggested code: synchronize( oIOLocked ) { IOLocked++; } > >> BTW: wouldnt all run a whole lot better ( faster anyway ) if the rxtx >> synchronize directives be completely removed from reads and writes ( as >> well as the removal of IOLocked et al ) ? > > That's not my decision to make, it's more a political question whether > the library takes care of it or the end user developer. You can of > course remove it all and let the user take care of it... For some its what the docs say ( or suggest anyway ) > > If you ask me personally: I believe it makes perfect sense to do it in > the library. The speed impact is marginal. But it touches the integrity > of the library state (since IOLocked cannot be influenced directly from > outside). If you cannot close the port because an internal variable's > content is damaged, that is nothing to be handled by the end user dev. > From my point of view it's the library's responsibility. The point being is that IOLocked is not necessary for the integrity or the state of the library. Nor is the ( forced upon you ) synchronized reads. thats an IMHO. > > But I'm tired of "defending" my position here. If you think, it is ok > how it is done at the moment: I'm not sure what u mean? For my USB/serial io device, rxtx spins & spins. So its not OK at the moment. When I remove (unplug) the serial device, it also spins and spins. Also not an OK situation. And I really hate it when a close() refuses to do so! fine, let's end that discussion here. I thought we were addressing bugs. From Martin.Oberhuber at windriver.com Tue Dec 11 09:48:38 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 17:48:38 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475C3F3B.9050003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> U.George wrote: BTW: Since JAVA source went public, sorta, did java publish the commapi source? Sun is publishing the OpenJDK under GPL 2 (with "classpath exception" for SOME files only, see the last paragraph of following link): http://openjdk.java.net/legal/gplv2+ce.html whereas RXTX is under (modified) LGPL. Please DONT go copy&paste GPL'd Sun code into LGPL'd RXTX. That would be a BIG problem at least for some companies using RXTX. GPL is viral in that it might force companies open-source their proprietary stuff if they link against a GPL'd lib! LGPL is not that viral, at least not when linking dynamically. We'd really have a problem when RXTX is infected with GPL'd code fragments. Therefore, please DONT even try finding the GPL'd Sun code, read it or reference it otherwise. It's really a big threat. Really. Thanks, Martin From Martin.Oberhuber at windriver.com Tue Dec 11 10:04:20 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:04:20 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BE327.9010709@gmail.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> <475BE327.9010709@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B23@ism-mail03.corp.ad.wrs.com> Hi Beat, > Should I setup my code such that all accesses > to the serial port happen in one unique thread? > Would this prevent the problems that are described? Yes, I think that accessing your RXTXPort from a single thread should work around all the issues discussed here. One option for doing so might be if you create a "frontend" for your RXTXPort like a PipedStream that runs in a single thread but accepts input from multiple threads. Such code could be based on a BoundedBufferWithStateTracking See http://gee.cs.oswego.edu/dl/cpj/allcode.java and http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.core/terminal/or g.eclipse.tm.terminal/src/org/eclipse/tm/internal/terminal/textcanvas/Pi pedInputStream.java?root=DSDP_Project&view=markup Cheers, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/41f74564/attachment-0003.html From Martin.Oberhuber at windriver.com Tue Dec 11 10:05:56 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:05:56 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B26@ism-mail03.corp.ad.wrs.com> U.George wrote: > close should set a flag, that would cause any further > I/O requests to throw an exception ). +1, I fully agree. Cheers, Martin From Martin.Oberhuber at windriver.com Tue Dec 11 10:09:06 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 11 Dec 2007 18:09:06 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47598A99.2010601@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47598A99.2010601@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803D47B2C@ism-mail03.corp.ad.wrs.com> > > try { > > getSerialPort().removeEventListener(); > > Thread.sleep(50); //allow a little time for RXTX Native to catch > > up > > whats there to catch up? > what that a patch for user code? or for RXTX ? This was a "hack workaround" in our user code that helped fixing an issue we had. I don't know why it works, but it works. With all the discusssions we've had so far, it should be possible to make close() thread-safe such that this workaround is not needed any more. Cheers Martin From netbeans at gatworks.com Tue Dec 11 10:11:04 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 12:11:04 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <20071211162630.GI2253@elberon.bln.de.ingenico.com> References: <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> <20071211162630.GI2253@elberon.bln.de.ingenico.com> Message-ID: <475EC4A8.6050204@gatworks.com> > So I think, having (or keeping, with some extensions / fixes) > this `threadsafety' as a lib feature keeps rxtx easily usable and > everyone would benefit :) Being synchronize'd does not guarantee the correct ordering of I/O operations. When the synchronized routine completes, all waiters are woken at the same time, and all have an opportunity ( but not all equal ) to obtain the sync'd routine. That type of coordination is beyond a library. From dwippermann at gmx.net Tue Dec 11 11:08:53 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Tue, 11 Dec 2007 19:08:53 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <836B0790-B266-46D8-B73A-48E4E85F82FD@gmx.net> <6EE5FE49-1E30-4E08-A752-BF5B169C0E72@gmx.net> <695CE8C6-D794-464A-9550-150C1501A09F@gmx.net> <2EBCCE74-ED5D-4F37-A56A-6266CCD983BA@gmx.net> Message-ID: <06C5F84B-E3F7-42E5-8248-42C03251F511@gmx.net> Hi all, > >> Those backward compatable routines are 'synchronize'd, so > >> should run no better that what rxtx is currently doing. > > > > Why do you think so? All write() methods in the SerialOutputStream > class > > are not synchronized at all at the moment. And the "synchronized" > read() > > methods only forbid to call more than one of them at any given time > > because they lock the SerialInputStream object they are living in. > But > > they have no locking influence on a concurrent write() and its > altering > > of IOLocked. So rxtx would do much better than what it is > currently doing. > Because, if you were to use the (AtomicInteger) > IOLocked.getAndIncrement(); u would get a hotspot/native operation in > JDK1.5 and JDK1.6, but with jdk1.3 & 1.4, with the backward compatible > routines, you would get the synchronise'd routine for getAndIncrement. > the JDK1.3 backward routine would be just as good as your suggested > code: > synchronize( oIOLocked ) { > IOLocked++; > } Oh, my fault. When I read "what rxtx is currently doing" I did not include my patch submission, since I do not count it as an official part of RXTX :) But yes, then you are right, it would make no difference in version prior to JDK5 and speed up things for all other versions. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071211/25160f31/attachment-0003.html From netbeans at gatworks.com Tue Dec 11 11:36:42 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 11 Dec 2007 13:36:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> Message-ID: <475ED8BA.6040403@gatworks.com> The Commapi was not published. Suns philosophy was to have people learn their methods and madness. Sun also believed that you will forget the particular code in a few weeks, rather than the usual 2 years. So it was written. But you seem to forget that in order to replicate the behavior of that code, u need to look at the DOCS. And when that is not specific enough, then there has to be other ways to get that information. For instance the InputStream.read() is not DOC'd as synchronized. Nor is FileInputStream.read synchronized ( as per inspection of the JDK source ). If I further investigate, probably none of the InputStream derivatives are synchronized. Now that I have stated this, does your compliance with DOC's, in the removal of the synchronize, also mean that you adopted another coding license? And if the commapi code were to be published, and did not have the synchronized read ( as per actual code ) would that type of information still not be persuasive? BTW: exactly where did u get the idea that I was advocating cut&paste of someone-else's code? You learn by reading other peoples code. And if you read enough you can sometimes perceive software genealogy. Oberhuber, Martin wrote: > U.George wrote: > BTW: Since JAVA source went public, sorta, did java publish the > commapi source? > > Sun is publishing the OpenJDK under GPL 2 (with "classpath exception" > for > SOME files only, see the last paragraph of following link): > http://openjdk.java.net/legal/gplv2+ce.html > whereas RXTX is under (modified) LGPL. > > Please DONT go copy&paste GPL'd Sun code into LGPL'd RXTX. > > That would be a BIG problem at least for some companies using RXTX. > GPL is viral in that it might force companies open-source their > proprietary stuff if they link against a GPL'd lib! LGPL is not that > viral, at least not when linking dynamically. We'd really have a > problem when RXTX is infected with GPL'd code fragments. > > Therefore, please DONT even try finding the GPL'd Sun code, > read it or reference it otherwise. It's really a big threat. > Really. > > Thanks, > Martin > > From hunor.bartha at ambo.ro Tue Dec 11 11:55:24 2007 From: hunor.bartha at ambo.ro (Bartha Hunor) Date: Tue, 11 Dec 2007 20:55:24 +0200 Subject: [Rxtx] rxtxParallel problem Message-ID: <475EDD1C.2040002@ambo.ro> Hi, Hope somebody is reading this :). I have been using RXTX for serial communication in my java application and it all worked beautifully, but recently i tried to use the parallel port, and i had no success. I get the infamous link error: Exception in thread "main" java.lang.UnsatisfiedLinkError: no rxtxParallel in java.library.path at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.LPRPort.(LPRPort.java:35) at gnu.io.RXTXCommDriver.getCommPort(RXTXCommDriver.java:810) at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:343) If i remove all the parallel port related code from my class and leave only the code that uses the serial port everything works ok, the rxtxSerial dll is successfully loaded. I want to mention that the two dll's are in the same directory so i don't understand why is the rxtxSerial.dll found but not the rxtxParallel.dll. I suspect that there is a problem with the parallel dll. I searhced the web about this but i could find little data on people actually using rxtx for parallel communication. Is there anybody who successfully used this under Windows XP SP2 and JDK 1.5? Thanks, hunor From hhinze at gno.de Wed Dec 12 02:54:14 2007 From: hhinze at gno.de (hhinze at gno.de) Date: Wed, 12 Dec 2007 10:54:14 +0100 (CET) Subject: [Rxtx] RXTX and Bluetooth Message-ID: <17538664.1197453254852.JavaMail.ngmail@webmail19> Hi everybody, I'm experiencing some problems when trying to use the rxtx package to access a Bluetooth module. I hope this is the right place to ask. What I want to do is: accessing data in Flash (Windows XP) which have been sent by a microcontroller. Therefor I want to send the data from a serial port to a net port to be accessed over an IP. I use a RN-41 (Roving Networks) Bluetooth module with the Microcontroller. I can connect it with a Bluetooth dongle and get a usual serial COM port. This port can be connected to via several terminal progs (like Eltima e.g.) Then it's possible to communicate with the microcontroller over this terminal. What doesn't work is: when I try to connect to the "Bluetooth port" via the rxtx package it's invisible. I get a NoSuchPortException. It's only visible while I'm connected to the port with one of those terminal progs. But then the port is locked by the other application of course and can't be used. When I connect the microcontroller physically over a USB cable all works fine and I can use my rxtx server. I'm in the middle of my graduation project so I appreciate any help. Thanx Henner Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT F?R ALLE NEUEINSTEIGER Jetzt bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 29,95 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From Martin.Oberhuber at windriver.com Wed Dec 12 06:21:14 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 12 Dec 2007 14:21:14 +0100 Subject: [Rxtx] RXTX and Bluetooth In-Reply-To: <17538664.1197453254852.JavaMail.ngmail@webmail19> References: <17538664.1197453254852.JavaMail.ngmail@webmail19> Message-ID: <460801A4097E3D4CA04CC64EE648584803DB233E@ism-mail03.corp.ad.wrs.com> Hello Henner, try telling RXTX explicitly your port name: One option of doing so is System.setProperty("gnu.io.rxtx.SerialPorts", "YourPortName0"); for more details about manually specifying ports, see the source code in RXTXCommDriver.registerSpecifiedPorts(int) Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of hhinze at gno.de Sent: Wednesday, December 12, 2007 10:54 AM To: rxtx at qbang.org Subject: [Rxtx] RXTX and Bluetooth What doesn't work is: when I try to connect to the "Bluetooth port" via the rxtx package it's invisible. I get a NoSuchPortException. It's only visible while I'm connected to the port with one of those terminal progs. But then the port is locked by the other application of course and can't be used. From Martin.Oberhuber at windriver.com Wed Dec 12 06:34:26 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Wed, 12 Dec 2007 14:34:26 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475ED8BA.6040403@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com><47599422.4020003@gatworks.com><0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca><475B27F7.5040500@gatworks.com><475BD523.3000900@gatworks.com> <475C3F3B.9050003@gatworks.com> <460801A4097E3D4CA04CC64EE648584803D47B15@ism-mail03.corp.ad.wrs.com> <475ED8BA.6040403@gatworks.com> Message-ID: <460801A4097E3D4CA04CC64EE648584803DB2354@ism-mail03.corp.ad.wrs.com> Hi George, > exactly where did u get the idea that I was advocating > cut&paste of someone-else's code? You learn by reading > other peoples code. And if you read enough you can > sometimes perceive software genealogy. no offence meant, I didn't think you were advocating copy& paste. I just wanted people to be aware of potential GPL problems, and thus be careful. I'm not a lawyer, so I cannot guarantee that the following is true: but in my understanding, reading code in order to get ideas does not violate copyright because only a specific expression of code (read: verbatim copy) can be copyrighted. Algorithms, code structures and APIs can be patented but not copyrighted; thus, in terms of GPL'd code, only verbatim copy & paste is a real threat. That being said, reading DOCs should be OK. Even talking about particular aspects of implementation _should_ be OK. Still, I personally prefer being over-careful and not even digging into GPL code looking for information, if I can avoid it. Code scanners like BlackDuck will find code that has been taken from somewhere else. And if Sun wanted to be malicious to other companies, taking the GPL as a weapon, they have everything they need. So again, please be careful and use good judgement. Getting RXTX GPL-infested would be a problem for us. Thanks, Martin From ajmas at sympatico.ca Wed Dec 12 20:09:40 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Dec 2007 22:09:40 -0500 Subject: [Rxtx] Help me ,please In-Reply-To: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> References: <8191775.874261197288794663.JavaMail.coremail@bj163app62.163.com> Message-ID: <298B975C-A04C-4516-8A61-9BE8E887B936@sympatico.ca> You need to get the latest code from CVS, since this issue has been resolved since: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code You'll want the code from the 2.1 branch. Andre On 10-Dec-07, at 07:13 , ?? wrote: > > > I used a common-user in the MAC OS 10.5. When i used rxtx 21.7 to > open the serial port on the MAC OS 10.5.the rxtx has a error. > how can I do ? thanks > > description: > error testing lock file creation error details:permission > deniedcheck_lock_status:no perminssion to create lock file. > please see: how can I use lock files with rxtx ? in install > > > ?????????? ?????????????? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Wed Dec 12 20:12:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Dec 2007 22:12:30 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? In-Reply-To: <475D4901.7030503@verizon.net> References: <47576BBD.1050703@verizon.net> <475D4901.7030503@verizon.net> Message-ID: <01A13D6F-BA2C-4086-B62A-3F34B613D689@sympatico.ca> On 10-Dec-07, at 09:11 , Bill Christens-Barry wrote: > Andre, > > Thanks for this. I'm not on top of using cvs, but I was able to > follow the instructions on the CVS page of the rxtx site to get the > code (via "cvs checkout rxtx-devel"). Is this the right branch? Not > having read any readmes etc. that may be in the project, I'm not > sure now how I go about doing a build - are there any special tools > I need for this to run on a MacBook Pro Core2Duo intel? I have the > usual developer tools, but am unsure about various libraries that > may be needed. > > Incidentally, I was able to get the version I mentioned in my list > posting by creating a lock folder. I'm not sure what repercussions > this may have, so I'm Hi, Instruction for getting from CVS: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and building on MacOS X: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X Let me know if they help. Andre From fabioanjos at gmail.com Thu Dec 13 04:25:38 2007 From: fabioanjos at gmail.com (=?ISO-8859-1?Q?F=E1bio_Cristiano_dos_Anjos?=) Date: Thu, 13 Dec 2007 09:25:38 -0200 Subject: [Rxtx] Building RXTX in Windows Message-ID: <29788b250712130325r24e31afeu54a2f4eb72af612c@mail.gmail.com> Hi, I checked out RXTX from cvs, and then I tried to build it for Windows following the instructions in http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows. Are those procedures updated? I tried firts with MinGW, then the folowing errors ocurred: C:\dev\workspace\rxtx-devel\build>make MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. Error makefile 95: No match found for wildcard '/*.java)' Error makefile 95: No match found for wildcard '/*.c)' Error makefile 95: No match found for wildcard '/*.cc)' *** 3 errors during make *** Then I tried with lcc: C:\dev\workspace\rxtx-devel\src>make -f ..\Makefile.lcc MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. lcc -I\JDK\INCLUDE -I\jdk\include\win32 -I. SerialImp.c cpp: c:\dev\workspace\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 Could no t find include file Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `void' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 syntax error; found `*' expecting ')' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 skippi ng `*' `,' `jclass' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 extran eous old-style parameter list Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `jint' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `JNICALL' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 redefi nition of 'JNICALL' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 Previo us definition of 'JNICALL' here Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_open' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 syntax error; found `*' expecting ')' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 skippi ng `*' `,' `jobject' `,' `jstring' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 extran eous old-style parameter list Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `jint' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `JNICALL' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 Syntax error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 syntax error; found `*' expecting ')' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 skippi ng `*' `,' `jobject' `,' `jint' Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 extran eous old-style parameter list Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 Syntax error; missing semicolon before `jint' Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 no t ype specified. Defaulting to int Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 too ma ny errors ** error 1 ** deleting SerialImp.obj Any help apreciated! -- F?bio Cristiano dos Anjos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071213/f0befaa2/attachment-0001.html From ajmas at sympatico.ca Thu Dec 13 07:15:31 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 13 Dec 2007 09:15:31 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? In-Reply-To: References: <47576BBD.1050703@verizon.net> <475D4901.7030503@verizon.net> <01A13D6F-BA2C-4086-B62A-3F34B613D689@sympatico.ca> <4760B475.1050900@verizon.net> Message-ID: <3708825F-4C31-4DA0-AB81-783AC1AE2777@sympatico.ca> On 12-Dec-07, at 23:26 , Bill Christens-Barry wrote: > Andre, > > Thanks for following up on this. Yes, I tried the links you give but > ran into trouble during the build in Xcode. There were 101 errors, > all of which I believe were related to the single, first error that > had to do with the absence of javax.comm. I can't give you any more > detail, as it was several days ago that I tried this. This was on a > Powerbook G4 running Mac OS 10.4.11, with a recent version of Xcode. One other thing, is that while you can use xcode, you can also build everything from the command line: ./configure make I wrote some instructions here: http://rxtx.qbang.org/wiki/index.php/Installation_on_MacOS_X If there are problems with them, then I will update them. Andre PS Please try to keep mailings on the list, so others can benefit. From ajmas at sympatico.ca Thu Dec 13 07:15:49 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 13 Dec 2007 09:15:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? In-Reply-To: <8CCAEEDB-9311-4EB9-AC18-52F074C857A3@sympatico.ca> References: <47576BBD.1050703@verizon.net> <475D4901.7030503@verizon.net> <01A13D6F-BA2C-4086-B62A-3F34B613D689@sympatico.ca> <4760B475.1050900@verizon.net> <8CCAEEDB-9311-4EB9-AC18-52F074C857A3@sympatico.ca> Message-ID: On 12-Dec-07, at 23:26 , Bill Christens-Barry wrote: > Andre, > > Thanks for following up on this. Yes, I tried the links you give but > ran into trouble during the build in Xcode. There were 101 errors, > all of which I believe were related to the single, first error that > had to do with the absence of javax.comm. I can't give you any more > detail, as it was several days ago that I tried this. This was on a > Powerbook G4 running Mac OS 10.4.11, with a recent version of Xcode. Are you sure you are building the code from the 2.1 branch? This error sounds symptomatic of an attempt to build code from the 2.0 branch. Andre From tjarvi at qbang.org Thu Dec 13 08:05:42 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 13 Dec 2007 08:05:42 -0700 (MST) Subject: [Rxtx] Building RXTX in Windows In-Reply-To: <29788b250712130325r24e31afeu54a2f4eb72af612c@mail.gmail.com> References: <29788b250712130325r24e31afeu54a2f4eb72af612c@mail.gmail.com> Message-ID: On Thu, 13 Dec 2007, F?bio Cristiano dos Anjos wrote: > Hi, > > I checked out RXTX from cvs, and then I tried to build it for > Windows following the instructions in > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows. > > Are those procedures updated? > > I tried firts with MinGW, then the folowing errors ocurred: > > C:\dev\workspace\rxtx-devel\build>make > MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. > Error makefile 95: No match found for wildcard '/*.java)' > Error makefile 95: No match found for wildcard '/*.c)' > Error makefile 95: No match found for wildcard '/*.cc)' > *** 3 errors during make *** > > Then I tried with lcc: > > C:\dev\workspace\rxtx-devel\src>make -f ..\Makefile.lcc > MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. > lcc -I\JDK\INCLUDE -I\jdk\include\win32 -I. SerialImp.c > cpp: c:\dev\workspace\rxtx-devel\src\gnu_io_rxtxport.h:2 serialimp.c:64 > Could no > t find include file > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 > Syntax > error; missing semicolon before `void' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 > Syntax > error; missing semicolon before `Java_gnu_io_RXTXPort_Initialize' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 > syntax > error; found `*' expecting ')' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 > skippi > ng `*' `,' `jclass' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 64 > extran > eous old-style parameter list > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > Syntax > error; missing semicolon before `jint' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > Syntax > error; missing semicolon before `JNICALL' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > redefi > nition of 'JNICALL' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 63 > Previo > us definition of 'JNICALL' here > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > Syntax > error; missing semicolon before `Java_gnu_io_RXTXPort_open' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 71 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 > syntax > error; found `*' expecting ')' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 > skippi > ng `*' `,' `jobject' `,' `jstring' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 72 > extran > eous old-style parameter list > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 > Syntax > error; missing semicolon before `jint' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 > Syntax > error; missing semicolon before `JNICALL' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 > Syntax > error; missing semicolon before `Java_gnu_io_RXTXPort_nativeGetParity' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 79 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 > syntax > error; found `*' expecting ')' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 > skippi > ng `*' `,' `jobject' `,' `jint' > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 80 > extran > eous old-style parameter list > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 > Syntax > error; missing semicolon before `jint' > Warning c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 > no t > ype specified. Defaulting to int > Error c:\dev\workspace\rxtx-devel\src\serialimp.c: gnu_io_rxtxport.h: 87 > too ma > ny errors > ** error 1 ** deleting SerialImp.obj > Any help apreciated! > > You probably want to use GNU make. Especially with mingw32. The -I lines need to be changed with lcc. They should point to the include directories that come with your JDK. lcc instructions are not updated very often. Not many people use it. They should be close enough to get you going though. Some of the path variables in the makefile will need to be adjusted for you filesystem layout. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Thu Dec 13 09:32:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 13 Dec 2007 11:32:30 -0500 Subject: [Rxtx] Building RXTX in Windows Message-ID: <6bpm1d$51c4do@toip4.srvr.bell.ca> "F?bio Cristiano dos Anjos" wrote: > > Hi, > > I checked out RXTX from cvs, and then I tried to build it for > Windows following the instructions in > http://rxtx.qbang.org/wiki/index.php/Installation_on_MS-Windows. > > Are those procedures updated? > I suspect that they aren't up to date. If anyone has any experience building RXTX on Windows, could I ask for you to check the instructions and update them as necessary. The sort of things that would be worth mentioning: - required tools & environment variables - build steps Thanks Andre -------------- next part -------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From vorobyev.a at gmail.com Fri Dec 14 01:16:27 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Fri, 14 Dec 2007 11:16:27 +0300 Subject: [Rxtx] Building rxtx in Linux / Problem after install Message-ID: <47623BDB.90604@gmail.com> Good day. I have build rxtx from souce and copy *.so to /lib linux-fceg:/lib # ll /lib/librxtx* lrwxrwxrwx 1 root root 18 Dec 13 19:41 /lib/librxtxParallel-2.1-7.so -> librxtxParallel.so -rwxr-xr-x 1 root root 7696 Dec 13 19:52 /lib/librxtxParallel.so lrwxrwxrwx 1 root root 16 Dec 13 19:41 /lib/librxtxSerial-2.1-7.so -> librxtxSerial.so -rwxr-xr-x 1 root root 38936 Dec 13 19:52 /lib/librxtxSerial.so run program: ==================================================== java.lang.UnsatisfiedLinkError: gnu.io.RXTXCommDriver.nativeGetVersion()Ljava/lang/String; thrown while loading gnu.io.RXTXCommDriver java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver After that i have compared new and original natile library. New: linux-fceg:/lib # nm librxtxSerial.so 00001470 T Java_gnu_io_CommPortIdentifier_native_1psmisc_1report_1owner 00002f08 a _DYNAMIC 00002ff4 a _GLOBAL_OFFSET_TABLE_ w _Jv_RegisterClasses 00002ef8 d __CTOR_END__ 00002ef4 d __CTOR_LIST__ 00002f00 d __DTOR_END__ 00002efc d __DTOR_LIST__ 000015c0 r __FRAME_END__ 00002f04 d __JCR_END__ 00002f04 d __JCR_LIST__ 00003078 A __bss_start w __cxa_finalize@@GLIBC_2.1.3 00001500 t __do_global_ctors_aux 00000a30 t __do_global_dtors_aux 00003070 d __dso_handle w __gmon_start__ 00000ac7 t __i686.get_pc_thunk.bx U __lxstat@@GLIBC_2.0 U __strdup@@GLIBC_2.0 U __strtol_internal@@GLIBC_2.0 U __xstat@@GLIBC_2.0 00003078 A _edata 000031a0 A _end 00001534 T _fini 00000824 T _init U chdir@@GLIBC_2.0 U closedir@@GLIBC_2.0 00003080 b completed.6049 U exit@@GLIBC_2.0 U fclose@@GLIBC_2.1 00003088 b files U fopen@@GLIBC_2.1 00003090 b found_item 00000a90 t frame_dummy U fscanf@@GLIBC_2.0 U fwrite@@GLIBC_2.0 U getpid@@GLIBC_2.0 U getpwuid@@GLIBC_2.0 U getuid@@GLIBC_2.0 0000308c b last.5254 00003084 b last_named U malloc@@GLIBC_2.0 U opendir@@GLIBC_2.0 00003074 d p.6047 00000ad0 T parse_args U perror@@GLIBC_2.0 U readdir@@GLIBC_2.0 000030a0 B returnstring 00000c60 T scan_fd U seteuid@@GLIBC_2.0 00001090 T show_user U sprintf@@GLIBC_2.0 U stderr@@GLIBC_2.0 U strcat@@GLIBC_2.0 U strcmp@@GLIBC_2.0 U strcpy@@GLIBC_2.0 Original: /*00001198 T Java_gnu_io_LPRPort_Initialize 00001744 T Java_gnu_io_LPRPort_eventLoop 00001908 T Java_gnu_io_LPRPort_getInputBufferSize 00000fb0 T Java_gnu_io_LPRPort_getOutputBufferFree 0000191c T Java_gnu_io_LPRPort_getOutputBufferSize 0000101c T Java_gnu_io_LPRPort_isPaperOut 00001068 T Java_gnu_io_LPRPort_isPrinterBusy 000010b4 T Java_gnu_io_LPRPort_isPrinterError 00001100 T Java_gnu_io_LPRPort_isPrinterSelected 0000114c T Java_gnu_io_LPRPort_isPrinterTimedOut 00001254 T Java_gnu_io_LPRPort_nativeClose 000016cc T Java_gnu_io_LPRPort_nativeavailable 000011e0 T Java_gnu_io_LPRPort_open 00001578 T Java_gnu_io_LPRPort_readArray 000014e4 T Java_gnu_io_LPRPort_readByte 0000173c T Java_gnu_io_LPRPort_setHWFC 00001900 T Java_gnu_io_LPRPort_setInputBufferSize 00000fd8 T Java_gnu_io_LPRPort_setLPRMode 00001914 T Java_gnu_io_LPRPort_setOutputBufferSize 000012f4 T Java_gnu_io_LPRPort_writeArray 0000128c T Java_gnu_io_LPRPort_writeByte*/ 00002e38 a _DYNAMIC 00002f20 a _GLOBAL_OFFSET_TABLE_ 00002e2c d __CTOR_END__ 00002e28 d __CTOR_LIST__ 00002e34 d __DTOR_END__ 00002e30 d __DTOR_LIST__ 00002e24 d __EH_FRAME_BEGIN__ 00002e24 d __FRAME_END__ 00002fa0 A __bss_start w __cxa_finalize@@GLIBC_2.1.3 w __deregister_frame_info@@GLIBC_2.0 00001c04 t __do_global_ctors_aux 00000eb4 t __do_global_dtors_aux 00002f94 d __dso_handle U __errno_location@@GLIBC_2.0 w __gmon_start__ w __register_frame_info@@GLIBC_2.0 00002fa0 A _edata 00002fb8 A _end 00001c50 T _fini 00000cb8 T _init 00000e80 t call_gmon_start U close@@GLIBC_2.0 00002f9c d completed.1 00000f50 t fini_dummy 00002fa0 d force_to_data 00002fa0 d force_to_data U fprintf@@GLIBC_2.0 00000f60 t frame_dummy U free@@GLIBC_2.0 00000eb0 t gcc2_compiled. 00001c00 t gcc2_compiled. 00001b90 T get_java_var 00000fa0 t init_dummy 00001c40 t init_dummy U ioctl@@GLIBC_2.0 00001a70 T is_interrupted U malloc@@GLIBC_2.0 00002fa0 b object.2 U open@@GLIBC_2.0 00002f98 d p.0 U printf@@GLIBC_2.0 U read@@GLIBC_2.0 000013b8 T read_byte_array 00001a68 T report 00001a3c T report_error U select@@GLIBC_2.0 00001afc T send_event U sigaction@@GLIBC_2.0 U signal@@GLIBC_2.0 U sprintf@@GLIBC_2.0 U stderr@@GLIBC_2.0 U strerror@@GLIBC_2.0 00001928 T throw_java_exception 000019f8 T throw_java_exception_system_msg U usleep@@GLIBC_2.0 U write@@GLIBC_2.0 Why there are no several functions in my build? How to make correct build? From netbeans at gatworks.com Fri Dec 14 04:47:43 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 14 Dec 2007 06:47:43 -0500 Subject: [Rxtx] Building rxtx in Linux / Problem after install In-Reply-To: <47623BDB.90604@gmail.com> References: <47623BDB.90604@gmail.com> Message-ID: <47626D5F.20107@gatworks.com> [gat at mylaptop RXTX]$ find . -type f -exec grep -l nativeGetVersion {} \; ./RXTX-2.0/gnu_io_RXTXCommDriver.h ./RXTX-2.0/SerialImp.lo ./RXTX-2.1/librxtxSerial-2.1-7.so ./RXTX-2.1/SerialImp.o [gat at mylaptop RXTX]$ > java.lang.UnsatisfiedLinkError: > gnu.io.RXTXCommDriver.nativeGetVersion()Ljava/lang/String; thrown while > loading gnu.io.RXTXCommDriver > java.lang.NoClassDefFoundError: Could not initialize class > gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver From vorobyev.a at gmail.com Fri Dec 14 08:30:58 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Fri, 14 Dec 2007 18:30:58 +0300 Subject: [Rxtx] Building rxtx in Linux / Problem after install Message-ID: <4762A1B2.2070304@gmail.com> vorobyev.a at linux-fceg:/usr/src/rxtx-2.1-7r2> find . -type f -exec grep -l nativeGetVersion {} \; ./WinCE/gnu_io_RXTXCommDriver.cpp ./WinCE/gnu_io_RXTXCommDriver.h ./CNI/RXTXCommDriver.java ./CNI/SerialImp.c ./gnu/io/RXTXVersion.class ./gnu/io/RXTXCommDriver.class ./i686-pc-linux-gnu/gnu_io_RXTXVersion.h ./i686-pc-linux-gnu/.libs/SerialImp.o ./i686-pc-linux-gnu/gnu_io_RXTXCommDriver.h ./MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/librxtxSerial.jnilib ./MACOSX_IDE/ForPackageMaker/Install/Library/Java/Extensions/RXTXcomm.jar ./src/Serial.def ./src/RXTXVersion.java ./src/RXTXCommDriver.java ./src/SerialImp.c I have build rxtx under centos 4. Similar result vorobyev.a at linux-fceg:/usr/src/rxtx-2.1-7r2> gcc --version gcc (GCC) 4.2.1 (SUSE Linux) vorobyev.a at linux-fceg:/usr/src/rxtx-2.1-7r2> java -version java version "1.6.0_02" From vorobyev.a at gmail.com Fri Dec 14 09:23:36 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Fri, 14 Dec 2007 19:23:36 +0300 Subject: [Rxtx] Building rxtx in Linux / Problem after install Message-ID: <4762AE08.6060508@gmail.com> linux-fceg:/usr/src/rxtx-2.1-7r2 # make install make all-am make[1]: Entering directory `/usr/src/rxtx-2.1-7r2' make[1]: Leaving directory `/usr/src/rxtx-2.1-7r2' libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 From netbeans at gatworks.com Fri Dec 14 06:24:37 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 14 Dec 2007 08:24:37 -0500 Subject: [Rxtx] Building rxtx in Linux / Problem after install In-Reply-To: <4762A1B2.2070304@gmail.com> References: <4762A1B2.2070304@gmail.com> Message-ID: <47628415.7050409@gatworks.com> If you will notice, in my build(s), that only RXTX2.1 has it defined in a .so not RXTX 2.0 From netbeans at gatworks.com Fri Dec 14 06:29:29 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 14 Dec 2007 08:29:29 -0500 Subject: [Rxtx] Building rxtx in Linux / Problem after install In-Reply-To: <4762A1B2.2070304@gmail.com> References: <4762A1B2.2070304@gmail.com> Message-ID: <47628539.8030205@gatworks.com> 1) get 2.1 2) build it there ( ie ./configure; make ) 3) look for the missing linkage 3a) still missing - call back here 4) go back to your java devel site 5) export LD_LIBRARY_PATH=/path_to_build_shares/ 6) export CLASSPATH=/pathtothecommapi 7) java ......... ( dont use -jar ) A lexander Vorobyev wrote: > vorobyev.a at linux-fceg:/usr/src/rxtx-2.1-7r2> find . -type f -exec grep From tophi at laposte.net Sat Dec 1 04:06:24 2007 From: tophi at laposte.net (Christophe GAILLARD) Date: Sat, 01 Dec 2007 12:06:24 +0100 Subject: [Rxtx] Fulll serial port name ... Message-ID: <47514030.80100@laposte.net> Hello all, Is there a way to have the full serial port name as it appear in peripheral managment (Windows). ex : Prolific USB-to-Serial Comm Port (COM3) I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full serial port name) Thanks, Christophe From tjarvi at qbang.org Sat Dec 1 12:06:53 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 12:06:53 -0700 (MST) Subject: [Rxtx] Fulll serial port name ... In-Reply-To: <47514030.80100@laposte.net> References: <47514030.80100@laposte.net> Message-ID: On Sat, 1 Dec 2007, Christophe GAILLARD wrote: > Hello all, > Is there a way to have the full serial port name as it appear in > peripheral managment (Windows). > ex : Prolific USB-to-Serial Comm Port (COM3) > I'm interesting to get "Prolific USB-to-Serial Comm Port" (the full > serial port name) Hi Christophe, That information is not provided by the fairly simple Serial API rxtx uses. That type of information is probably available through USB HID. JSR80 provides that API. As far as RXTX knows, your Serial device is soldered to your motherboard :) -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat Dec 1 18:04:02 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 18:04:02 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4750A944.7010504@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: On Fri, 30 Nov 2007, U. George wrote: > U. George wrote: >> Box is a PIII laptop, with a USB 1 port. Device is a serialUSB device ( as >> per linux/redhat ) >> Debugging is not terribly easy on LINUX when there are pthreads > > The issue seems to be a mis-coordination of the "drain_loop" thread use of > the eis struct which is created from the "RXTXPort(eventLoop)" stack. > Once the flag eis.closing is set, the call to event loop is completed, and > the stack space is released ( re-used ). > unfortunately drain_loop still appears to be using the data, as the > pthread_kill() signal has yet to be processed by the drain_loop thread. > > The pthread_join() could be used here to wait for the drain_loop thread to > terminate. It might work if the pthread_detach() is *not* used, which > unfortunately is called by the thread creator as well as the thread itself :{ > It may be that the detach is not needed? When I put the pthread code into rxtx, I was just reading examples and trying to get it work. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sat Dec 1 19:11:36 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 01 Dec 2007 21:11:36 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> Message-ID: <47521458.2080908@gatworks.com> > > It may be that the detach is not needed? When I put the pthread code > into rxtx, I was just reading examples and trying to get it work. My issue is this statement in the code: > /* > Under normal conditions, SIGABRT will unblock tcdrain. However > a non-responding USB device combined with an unclean driver > may still block. This is very ugly because it may block the call > to close indefinetly. > */ With pthread_detach() the background task that is doing the tcdrain may hang, and the pthread_join() *wont* also deadlock because of the stuck thread. Because the struct eis is from the parent threads stack, u really cant release the stack that is in use by the parent thread via the return, as that would corrupt the eis struct, which is still in use by the child thread. In either case the com port device is stuck, and most likely not closeable, or reopenable anymore. It would be nice to be able to recover from this situation. But i dont think you will be able to do so. What would you like to do ? What is your preference? From tjarvi at qbang.org Sat Dec 1 19:47:31 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 1 Dec 2007 19:47:31 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <47521458.2080908@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: On Sat, 1 Dec 2007, U. George wrote: > >> >> It may be that the detach is not needed? When I put the pthread code into >> rxtx, I was just reading examples and trying to get it work. > > My issue is this statement in the code: >> /* >> Under normal conditions, SIGABRT will unblock tcdrain. However >> a non-responding USB device combined with an unclean driver >> may still block. This is very ugly because it may block the call >> to close indefinetly. >> */ > > With pthread_detach() the background task that is doing the tcdrain may hang, > and the pthread_join() *wont* also deadlock because of the stuck thread. > Because the struct eis is from the parent threads stack, u really cant > release the stack that is in use by the parent thread via the return, as that > would corrupt the eis struct, which is still in use by the child thread. > > In either case the com port device is stuck, and most likely not closeable, > or reopenable anymore. It would be nice to be able to recover from this > situation. But i dont think you will be able to do so. > > What would you like to do ? What is your preference? > That comment suggests we may have good kernel drivers or hardware too. In the w32 world, bugs like this showed up all over the place and went away for the most part with new drivers. To me, this sounds like a kernel bug. Maybe we should contact someone like Greg K-H and see if the problem can't be resolved rather than worked around. I think he sheperds the USB drivers. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 2 05:52:33 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 02 Dec 2007 07:52:33 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> Message-ID: <4752AA91.2040205@gatworks.com> Trent Jarvi wrote: > On Sat, 1 Dec 2007, U. George wrote: > >> >>> >>> It may be that the detach is not needed? When I put the pthread code >>> into rxtx, I was just reading examples and trying to get it work. >> >> My issue is this statement in the code: >>> /* >>> Under normal conditions, SIGABRT will unblock tcdrain. However >>> a non-responding USB device combined with an unclean driver >>> may still block. This is very ugly because it may block the call >>> to close indefinetly. >>> */ >> >> With pthread_detach() the background task that is doing the tcdrain >> may hang, and the pthread_join() *wont* also deadlock because of the >> stuck thread. >> Because the struct eis is from the parent threads stack, u really cant >> release the stack that is in use by the parent thread via the return, >> as that would corrupt the eis struct, which is still in use by the >> child thread. >> >> In either case the com port device is stuck, and most likely not >> closeable, or reopenable anymore. It would be nice to be able to >> recover from this situation. But i dont think you will be able to do so. >> >> What would you like to do ? What is your preference? >> > > That comment suggests we may have good kernel drivers or hardware too. > In the w32 world, bugs like this showed up all over the place and went > away for the most part with new drivers. > > To me, this sounds like a kernel bug. Maybe we should contact someone > like Greg K-H and see if the problem can't be resolved rather than > worked around. I think he sheperds the USB drivers. Im not sure of your reply. As new USB drivers are developed, things will break. As new USB devices are created, new drivers will be developed, annd things will break again. As the works turns, things will break. At issue is how carefull, if at all, for such errant kernel coding designs. For instance, sometines the disk I/O does into an unrecoverable "D" state. That process has died wait state , and cannot be killed. There is nothing that an application programmer can do. The only thing that can be done is to shutdown the system, and reboot. Since the RXTX comment in your code appears to want to handle such USB driver errors, I'd like to know if your catastrophic device error/hang strategy is still of your concern? My strategy would be to believe that the system device calls will not hang. And if they did, post an eratta to the device driver developer. From zuran at pandora.be Sun Dec 2 07:10:08 2007 From: zuran at pandora.be (Danny Dom) Date: Sun, 2 Dec 2007 15:10:08 +0100 Subject: [Rxtx] examples Message-ID: <003301c834ed$0b950c30$a601a8c0@dannycomp> Hi, I am busy with a project for reading temperatures from an AVR controller. This works either by sending a command to the controller for reading a specific temperature. And also for reading the complete log of all temperature during 1 day. I have implemented the RXTX api, but as far as I see i am only using the standard comm part of the api. I want to make a secure communication, maybe using CRC 8, flow control .. I want to use buffering, and the eventlistener to notify when there is new data. But so far I did not find a proper example of all this, how to implement the listener at an nice OO way. anyone that can help me Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071202/5d539c0d/attachment-0013.html From tjarvi at qbang.org Sun Dec 2 09:37:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:37:35 -0700 (MST) Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: <4752AA91.2040205@gatworks.com> References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: On Sun, 2 Dec 2007, U. George wrote: > Trent Jarvi wrote: >> On Sat, 1 Dec 2007, U. George wrote: >> >>> >>>> >>>> It may be that the detach is not needed? When I put the pthread code >>>> into rxtx, I was just reading examples and trying to get it work. >>> >>> My issue is this statement in the code: >>>> /* >>>> Under normal conditions, SIGABRT will unblock tcdrain. However >>>> a non-responding USB device combined with an unclean driver >>>> may still block. This is very ugly because it may block the call >>>> to close indefinetly. >>>> */ >>> >>> With pthread_detach() the background task that is doing the tcdrain may >>> hang, and the pthread_join() *wont* also deadlock because of the stuck >>> thread. >>> Because the struct eis is from the parent threads stack, u really cant >>> release the stack that is in use by the parent thread via the return, as >>> that would corrupt the eis struct, which is still in use by the child >>> thread. >>> >>> In either case the com port device is stuck, and most likely not >>> closeable, or reopenable anymore. It would be nice to be able to recover >>> from this situation. But i dont think you will be able to do so. >>> >>> What would you like to do ? What is your preference? >>> >> >> That comment suggests we may have good kernel drivers or hardware too. In >> the w32 world, bugs like this showed up all over the place and went away >> for the most part with new drivers. >> >> To me, this sounds like a kernel bug. Maybe we should contact someone like >> Greg K-H and see if the problem can't be resolved rather than worked >> around. I think he sheperds the USB drivers. > > Im not sure of your reply. > > As new USB drivers are developed, things will break. As new USB devices are > created, new drivers will be developed, annd things will break again. As the > works turns, things will break. > At issue is how carefull, if at all, for such errant kernel coding designs. > For instance, sometines the disk I/O does into an unrecoverable "D" state. > That process has died wait state , and cannot be killed. There is nothing > that an application programmer can do. The only thing that can be done is to > shutdown the system, and reboot. > > Since the RXTX comment in your code appears to want to handle such USB driver > errors, I'd like to know if your catastrophic device error/hang strategy is > still of your concern? > My strategy would be to believe that the system device calls will not hang. > And if they did, post an eratta to the device driver developer. > That is what I would do too. There is nothing to be gained from hiding serious issues. What I've usually done in the past is mention the issues we have noticed to the kernel developers at the Ottawa Linux Symposium. At times we do ignore unusual behavior but these are for unusual conditions. For instance, someone may be trying to use a Wii over bluetooth over usb over serial. If we can ignore conditions that are really the device going out of range and it does not cause other problems, we do put code in to help now and then. That said, USB-Serial was an unusual use case early on so there may be code that does not belone there anymore. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Dec 2 09:44:20 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 2 Dec 2007 09:44:20 -0700 (MST) Subject: [Rxtx] examples In-Reply-To: <003301c834ed$0b950c30$a601a8c0@dannycomp> References: <003301c834ed$0b950c30$a601a8c0@dannycomp> Message-ID: On Sun, 2 Dec 2007, Danny Dom wrote: > Hi, > > I am busy with a project for reading temperatures from an AVR controller. > > This works either by sending a command to the controller for reading a > specific temperature. And also for reading the complete log of all > temperature during 1 day. > > I have implemented the RXTX api, but as far as I see i am only using the > standard comm part of the api. > > I want to make a secure communication, maybe using CRC 8, flow control > .. I want to use buffering, and the eventlistener to notify when there > is new data. > > But so far I did not find a proper example of all this, how to implement > the listener at an nice OO way. > The examples we do have are on the rxtx wiki and in the source code under the contrib directory. http://rxtx.qbang.org/wiki/index.php/Examples You will find that rxtx does not do anything that could be done in another API. Buffering needs to be done with InputBufferStream from the JDK. CRC is not implemented as that could be used by multiple APIs. So I expect you would find the listener examples in contrib of some use. You may want to post some example code of your own on the wiki when you find everything you are after. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Dec 4 14:56:39 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 16:56:39 -0500 Subject: [Rxtx] #undef TIOCSERGETLSR on LINUX In-Reply-To: References: <474ACFBE.5050406@gatworks.com> <474B8758.6010006@gatworks.com> <474D7831.5010300@gatworks.com> <4750A944.7010504@gatworks.com> <47521458.2080908@gatworks.com> <4752AA91.2040205@gatworks.com> Message-ID: <4755CD17.9080102@gatworks.com> > > That said, USB-Serial was an unusual use case early on so there may be > code that does not belone there anymore. > Attached is a diff of the changes I made that I think accomplishes both conditions: 1) drain_loop is SIGABRT'd and joined, if not stuck in device i/o wait. 2) If cannot do #1 ( ie device stuck ) within 10 seconds, then try canceling the thread ( which I hope destroys everything associated with the stuck thread ). Then join(). If join() waits, its bec the thread cannot be killed, and rest of task will probably die/stall soon thereafter. This works under linux ( with the #undef TIOCSERGETLSR ). Really need a device that gets stuck on demand to test out the thread cancel part. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071204/fc74e4af/attachment-0011.pl From alfonso.benot.morell at gmail.com Tue Dec 4 17:51:55 2007 From: alfonso.benot.morell at gmail.com (Alfonso Benot-Morell) Date: Wed, 5 Dec 2007 01:51:55 +0100 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events Message-ID: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Dear all, I have been testing the 'TwoWaySerialComm' example from the Documentation Wiki with a GPS device I must work with. When I just have to wait for one single response message from the device, that code works fine, but is unable to read any other message (in a row) from the device unless I type and send something in between. My program should be capable of reading messages from the device every X time (with X ranging from 0.1s to 1 hour). For this purpose, I slightly modified the code by implementing the SerialPortEventListener interface in the SerialReader nested class and setting notifyOnDataAvailable as true (then I had to pass a SerialPort object to the SerialReader constructor to add an event listener). After making some other modifications, my code remains as follows. --------------------------------------------------------------------------------------------------------------------------------------- import gnu.io.*; import java.util.*; import java.io.*; public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass ().getName(),20000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(115200,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.notifyOnDataAvailable(true); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); Thread th1 = new Thread(new SerialReader(in,serialPort)); Thread th2 = new Thread(new SerialWriter(out)); //th2.setPriority(Thread.MIN_PRIORITY); th1.start(); th2.start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** */ public static class SerialReader implements Runnable, SerialPortEventListener { InputStream in; BufferedReader buff; int numVeces; public SerialReader ( InputStream in, SerialPort sp ) { numVeces=0; this.in = in; try { sp.addEventListener(this); buff = new BufferedReader(new InputStreamReader(in)); } catch (TooManyListenersException tmle) { System.out.println("Too many listeners exception"); tmle.printStackTrace(); } } public void run () { /*System.out.println("Dentro de run"); while(true); */ int i = 0; try { while(true) { /*System.out.println("Esperando en run " + i++); wait(); System.out.println("He vuelto de la int");*/ } } catch (Exception e) {} } public void serialEvent(SerialPortEvent e) { /*byte[] buffer = new byte[1024]; int len = -1; int i = 0;*/ try { System.out.println("Exception called"); String line = buff.readLine(); System.out.println("Line read"); System.out.println(line); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } /** */ public static class SerialWriter implements Runnable { //DataOutputStream dataOutput; OutputStream out; public SerialWriter(OutputStream Inout) { this.out = Inout; //dataOutput = new DataOutputStream(Inout); } public void run () { try { int c ; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); System.out.println("Inside write loop"); } System.out.println("Outside write loop"); } catch ( IOException ioe ) { ioe.printStackTrace(); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM2"); } catch ( Exception e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } --------------------------------------------------------------------------------------------------------------------------------------- Unfortunately, it doesn't work properly either. After configuring the device so that it sends different kinds of messages (position, time and date,...) at different periods, no further reads are made, and I must exit the program (ctrl +c) and run it again if I want it to read the message row. When running the program for a second time (or even a third one), then it works fine and all the cyclic messages are correctly read and displayed but I don't understand why. I am aware it might have to do with the run() method in the SerialWriter nested class rather than with the performance of RXTX itself but I am a relatively new Java programmer and have run out of ideas. Please help! What modifications would you suggest for the code to work 100% properly ? Would it be better to write by events in the SerialWriter class? Thank you very much for your help and your time. Kind regards. Alfonso Benot-Morell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/0832897e/attachment-0011.html From netbeans at gatworks.com Tue Dec 4 18:54:59 2007 From: netbeans at gatworks.com (U. George) Date: Tue, 04 Dec 2007 20:54:59 -0500 Subject: [Rxtx] Modifying the 'TwoWaySerialComm' example to enable reading by events In-Reply-To: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> References: <7828521c0712041651h73ff021ha11c49b6f303558a@mail.gmail.com> Message-ID: <475604F3.6040601@gatworks.com> i think this is your issue: > System.out.println("Exception called"); > String line = buff.readLine(); > System.out.println("Line read"); > System.out.println(line); When you get a data avail notice, you really dont know if you got a full 'readline' of data - yet! I suppose if readline is incomplete ( ie no cr-lf ( or whatever )) your exception routine will deadlock, as no further events can be issued. It might be better if you just read whats *avail* on that event, and store/append it yourself ( stringbuffer? ) . When you get a full line, place that complete data in an arraylist ( or whatever ). subtract that data from the event stringbuffer. Notify someone that u got a full line. Then release the event. Don't cause a wait in your event handler. your event listener should have something like this: int len = this.in.read(buffer); if ( len > 0 ) System.out.print(new String(buffer,0,len)); return; There might also be an issue with readline concept of line termination is and that of the GPS itself. Alfonso Benot-Morell wrote: > Dear all, > > I have been testing the 'TwoWaySerialComm' example from the From lyon at docjava.com Wed Dec 5 05:44:02 2007 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 05 Dec 2007 07:44:02 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: Hi All, Has anyone tried making use of RXTX on an Intel Mac with Java Webstart? Thanks! - Doug From ajmas at sympatico.ca Wed Dec 5 16:13:55 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 18:13:55 -0500 Subject: [Rxtx] Wiki updates Message-ID: <6bpls7$518pg4@toip6.srvr.bell.ca> Hi, I have just spent a bit of time updating the Wiki, with regards to installation. I have reworked the page, breaking things down a bit, though I cheated a little on the Linux and MS-Windows installation instructions, since I don't currently have access to them - I am using MacOS X. If someone has some time please could you make sure that the instructions are current, since they seemed a little dated. If you feel that anything else, in the additions I have made, can be improved, feel free to improve them. Andre From ajmas at sympatico.ca Wed Dec 5 19:15:01 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 5 Dec 2007 21:15:01 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: On 5-Dec-07, at 07:44 , Dr. Douglas Lyon wrote: > Hi All, > Has anyone tried making use of RXTX on an Intel Mac > with Java Webstart? Hi, I have never used it myself in this context, but the questions makes me tempted to try. Just need to learn how to sign the JAR first. Andre From equipoise1 at verizon.net Wed Dec 5 20:25:49 2007 From: equipoise1 at verizon.net (Bill Christens-Barry) Date: Wed, 05 Dec 2007 22:25:49 -0500 Subject: [Rxtx] Using rxtx-2.1-7r2 under Mac OS 10.5.1, trying to resolve CommPortIdentifier problem ? Message-ID: <47576BBD.1050703@verizon.net> I'm encountering a problem getting the example based on SimpleWrite.java to work (see http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter). The problem I'm having is exactly as described in the archives (see http://mailman.qbang.org/pipermail/rxtx/2006-October/1600464.html). Apparently, this problem has been solved by others, but I can't figure out what to do. I don't really understand the "lock" problem described in this thread, nor the resolution of it described in subsequent thread msgs. In particular, I don't know what the lock file name would be, where I would find it (I don't see any file in locations described in the thread msgs), and what I should do to correct the problem. Can anyone clue me with specific steps that might work under this version (Leopard) of Mac OS X? Thanks. Bill Christens-Barry From bschlining at gmail.com Wed Dec 5 23:26:05 2007 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 5 Dec 2007 22:26:05 -0800 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: I use RXTX via web start on Mac; but so far only on PPC not intel. Why are you asking? > > > Has anyone tried making use of RXTX on an Intel Mac > > with Java Webstart? > > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071205/326bb942/attachment-0010.html From ajmas at sympatico.ca Thu Dec 6 06:41:30 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 6 Dec 2007 08:41:30 -0500 Subject: [Rxtx] Intel Mac and Webstart In-Reply-To: References: Message-ID: <03ADA435-5683-47DA-BEB4-5CC11D30B482@sympatico.ca> On 5-Dec-07, at 21:25 , Dr. Douglas Lyon wrote: > Hi Andre, > I think I might have gotten it to work (just now). > Would you like to try to beta test? > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Looks like it works. Andre From Martin.Oberhuber at windriver.com Fri Dec 7 10:28:05 2007 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 7 Dec 2007 18:28:05 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: Message-ID: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Hi Daniel, I've also seen issues with close and found the workaround that I sent to the RXTX mailing list on Oct 31: try { getSerialPort().removeEventListener(); Thread.sleep(50); //allow a little time for RXTX Native to catch up - makes stuff more stable } catch(Exception e) { Logger.logException(e); } getSerialPort().close(); You might also need the fixes that I've put into the CommPortIdentifier class, since the old code could hickup with multiple Threads and getPortIdentifier(). See http://bugzilla.qbang.org/show_bug.cgi?id=48 http://rxtx.qbang.org/eclipse/downloads Cheers, Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Daniel Wippermann Sent: Wednesday, November 28, 2007 4:47 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Dual Core Problem Hi all, > I am struggling with an application that uses RXTX 2.1.7 and has been > working reliably in the past. When this program runs on a dual-core DELL > (Intel T2500), strange things happen with the RS232 communication. The > application is missing incoming characters and also often freezes when > trying to close the serial port. I highly suspect a threading problem > and was wondering if a) anybody had run into a similar problem with dual > core processors and b) if there is a list of does and dont's when it > comes to RXTX and threads. I just stumbled over the same "freeze" of the application while trying to "close()" the RXTXPort. In this rare circumstances the "IOLocked" variable of the RXTXPort class still has a value greater than 0 although no action is pending. That makes the close() method sleep forever in expectation of some other thread to end its work... I believe this is caused by the "IOLocked++" and "IOLocked--" instructions not being synchronized. I suspect that in a multi-core- CPU environment there is a chance that this instructions may interfere if two threads are operating on the same port, but in different CPU cores. In my example the monitor thread is reading the port, while the main thread, that opened the port, is writing to it. I just changed my application so that every port handling method call is done from within a synchronized method or block. I have not observed another freeze since then, although I did an extensive stress test. But I think it would be nice if you could do the synchronisation from within the library in a future release. Best regards, Daniel _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From beat.arnet at gmail.com Fri Dec 7 10:57:56 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 12:57:56 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: Hello, I have followed Daniel's advice and encapsulated all access to the serial port using synchronized functions. However, I am a bit confused on how to deal with the serialEvent. Initially, I had only synchronized portions of the event handler where it accesses the InputStream. However, this caused dead-locks when trying to close the port while there were incoming characters. Now I have synchronized the function (synchronized void serialEvent) which eliminates the close dead-lock, but it looks as if the serialEvent does not attempt to acquire a lock and is capable of interrupting other synchronized statement in the same class. Do you have any recommendations on how to make the event handler thread-safe? Regards, Beat On Dec 7, 2007 12:28 PM, Oberhuber, Martin wrote: > Hi Daniel, > > I've also seen issues with close and found the > workaround that I sent to the RXTX mailing list > on Oct 31: > > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). > See > > http://bugzilla.qbang.org/show_bug.cgi?id=48 > > http://rxtx.qbang.org/eclipse/downloads > > Cheers, > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Daniel Wippermann > Sent: Wednesday, November 28, 2007 4:47 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Dual Core Problem > > Hi all, > > > I am struggling with an application that uses RXTX 2.1.7 and has been > > working reliably in the past. When this program runs on a dual-core > DELL > (Intel T2500), strange things happen with the RS232 > communication. > The > > application is missing incoming characters and also often freezes > when > trying to close the serial port. I highly suspect a threading > problem > and was wondering if a) anybody had run into a similar > problem with dual > core processors and b) if there is a list of does > and dont's when it > comes to RXTX and threads. > > I just stumbled over the same "freeze" of the application while trying > to "close()" the RXTXPort. In this rare circumstances the "IOLocked" > variable of the RXTXPort class still has a value greater than 0 although > no action is pending. That makes the close() method sleep forever in > expectation of some other thread to end its work... > > I believe this is caused by the "IOLocked++" and "IOLocked--" > instructions not being synchronized. I suspect that in a multi-core- CPU > environment there is a chance that this instructions may interfere if > two threads are operating on the same port, but in different CPU cores. > In my example the monitor thread is reading the port, while the main > thread, that opened the port, is writing to it. > > I just changed my application so that every port handling method call is > done from within a synchronized method or block. I have not observed > another freeze since then, although I did an extensive stress test. But > I think it would be nice if you could do the synchronisation from within > the library in a future release. > > Best regards, > Daniel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/d52f0bec/attachment-0008.html From netbeans at gatworks.com Fri Dec 7 11:02:01 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:02:01 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47598A99.2010601@gatworks.com> > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up whats there to catch up? what that a patch for user code? or for RXTX ? From netbeans at gatworks.com Fri Dec 7 11:42:42 2007 From: netbeans at gatworks.com (U. George) Date: Fri, 07 Dec 2007 13:42:42 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> Message-ID: <47599422.4020003@gatworks.com> u appear to be having a issue with programming in general. To avoid confusion, there should only one thread that is reading information from any 'serial' type of device. Having multiple threads reading the same serial ( or parallel, or USB ) does not work well, as each thread may obtain information that cannot be rewound back. Incomming chars, will be discarded on close. There shouldnt be a delay. SerialEvent will be passed to anyone that has added the serialevent interface. They will all be called by RXTX. If one thread wants to listen for a DSR then: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DSR: DataSetNowReady_routine(); } } If another thread want to know when data is avail: public void serialEvent(SerialPortEvent evt) { switch (evt.getEventType()) { case SerialPortEvent.DATA_AVAILABLE: { String s = read_in_the_data_routine(); Synchronized( arraylistofdatastrings ) { araylistofdataStrings.add(s); arraylistofdataStrings.notify(); } } } } or you can combine into one serialEvent routine. Somewhere in that same routine you have someone waiting for a string to appear in arraylistofdataStrings: Synchronized( arraylistofdataStrings ) { while( true ) { if ( arraylistofdataStrings.sizeof() == 0 ) { arraylistofdataStrings.wait( 1000 ); } else { s = arraylistofdataStrings.remove(0); break; } Beat Arnet wrote: > Hello, > I have followed Daniel's advice and encapsulated all access to the From beat.arnet at gmail.com Fri Dec 7 12:26:46 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Fri, 7 Dec 2007 14:26:46 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <47599422.4020003@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. Well, that's certainly what you get when electrical engineers like me write software ;) > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > But I am not talking about multiple threads reading from the same port. I am dealing with a case in which one thread is reading from the port, and another wants to close the port. > > Incomming chars, will be discarded on close. There shouldnt be a delay. > > SerialEvent will be passed to anyone that has added the serialevent > interface. They will all be called by RXTX. If one thread wants to > listen for a DSR then: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DSR: > DataSetNowReady_routine(); > } > } > > If another thread want to know when data is avail: > public void serialEvent(SerialPortEvent evt) { > > switch (evt.getEventType()) { > case SerialPortEvent.DATA_AVAILABLE: { > String s = read_in_the_data_routine(); > Synchronized( arraylistofdatastrings ) { > araylistofdataStrings.add(s); > arraylistofdataStrings.notify(); > } > } > } > } > > or you can combine into one serialEvent routine. > > > Somewhere in that same routine you have someone waiting for a string to > appear in arraylistofdataStrings: > > Synchronized( arraylistofdataStrings ) { > while( true ) { > if ( arraylistofdataStrings.sizeof() == 0 ) { > arraylistofdataStrings.wait( 1000 ); > } > else { > s = arraylistofdataStrings.remove(0); > break; > } > > Beat Arnet wrote: > > Hello, > > I have followed Daniel's advice and encapsulated all access to the > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071207/920ab071/attachment-0008.html From dwippermann at gmx.net Sat Dec 8 01:23:16 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sat, 8 Dec 2007 09:23:16 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <591F7B16-7DBA-4141-8D4F-11815A28A199@gmx.net> Hi all, > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. > That's true for my application as well and should be applicable to most apps that use event notification. The standard situation is that you have a GUI app that opens/closes the serial port in reaction to an UI event. Those actions would take place on the event dispatch thread. After opening the port you use addEventListener/notifyOnDataAvailable which starts a background monitor thread, which then calls your listener's implementation and hence reads the data. So you have one thread dedicated for reading (and all other events), but normally not reading from two different threads. So there should not be a problem... At least I thought so :) > try { > getSerialPort().removeEventListener(); > Thread.sleep(50); //allow a little time for RXTX Native to catch up > - makes stuff more stable > } catch(Exception e) { > Logger.logException(e); > } > getSerialPort().close(); > > You might also need the fixes that I've put into the > CommPortIdentifier class, since the old code could > hickup with multiple Threads and getPortIdentifier(). Thanks Martin, I'll look into that. But I'm still wondering why the IOLocked variable would retain a value not equal to 0 although all actions on the port have ended. The situations I debugged showed that the monitor thread was already terminated. Is the "Thread.sleep(50);" sufficient in all cases or are there any other means of determining whether the native part is ready to be closed? Thanks for your help, Daniel From ajmas at sympatico.ca Sat Dec 8 08:13:26 2007 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 8 Dec 2007 10:13:26 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> Message-ID: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> On 7-Dec-07, at 14:26 , Beat Arnet wrote: > > On Dec 7, 2007 1:42 PM, U. George wrote: > u appear to be having a issue with programming in general. > > > Well, that's certainly what you get when electrical engineers like > me write software ;) > > > To avoid confusion, there should only one thread that is reading > information from any 'serial' type of device. Having multiple threads > reading the same serial ( or parallel, or USB ) does not work well, as > each thread may obtain information that cannot be rewound back. > > > But I am not talking about multiple threads reading from the same > port. I am dealing with a case in which one thread is reading from > the port, and another wants to close the port. If you can you should assign the responsibility of closing the port to the one handling the port. The other thread should simply be telling the handling thread that it should close the port. Threads are like people, in that if you give them conflicting instructions all hell breaks loose. For example of what I think you should do: class MyClass { private boolean continueReading = true; public void run() { InputStream in = null; try { in = createMyInputStream(); // or however int len = 0; byte[] buffer = new byte[1024]; while ( (len = in.read(buffer)) > 0 && continueReading ) { // handle the read data } } catch ( IOException ex ) { } finally { if ( in != null ) { in.close(); } } } } Andre From netbeans at gatworks.com Sat Dec 8 16:25:43 2007 From: netbeans at gatworks.com (U. George) Date: Sat, 08 Dec 2007 18:25:43 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: <475B27F7.5040500@gatworks.com> >> But I am not talking about multiple threads reading from the same >> port. I am dealing with a case in which one thread is reading from the >> port, and another wants to close the port. > So I looked at the RXTX code ( close(), read() ) ( is that what u were trying to point out ? ) and it seems that a close() may not close. If there is heavy reading, then maybe close wont happen at all. Not sure why read is synchronized. If someone wants to read - uncoordinated, then that his option! But the read() and the close() does not appear to have a strong method of synchronization ( close should set a flag, that would cause any further I/O requests to throw an exception ). On would think that a close() would also prevent any further write() operations. But it does not. It also does not appear to wait for the write( b[] ) to complete ( in case the array has to be written out in chunks bec the kernel buffer is full. ) Does this help any? :-} From vorobyev.a at gmail.com Sun Dec 9 01:31:05 2007 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Sun, 09 Dec 2007 11:31:05 +0300 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? Message-ID: <475BA7C9.6090900@gmail.com> Good day. Following problem: Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Java 6 - 1.6.02 OS OpenSuse 10.3, 2.6.22.13-0.3-default I have attach USB printer: Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device found, idVendor=088c, idProduct=2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Product: TTP 2030 Dec 8 09:25:46 linux-fceg kernel: usb 1-2: Manufacturer: Swecoin AB Dec 8 09:25:46 linux-fceg kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x088C pid 0x2030 Dec 8 09:25:46 linux-fceg kernel: usbcore: registered new interface driver usblp Dec 8 09:25:46 linux-fceg kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver linux-fceg:/var/log # ll /dev/usb* lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 Example: Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { CommPortIdentifier portIdentifier = (CommPortIdentifier) portEnum.nextElement(); System.out.println(portIdentifier.getName() + " - " + getPortTypeName(portIdentifier.getPortType())); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial Virtual LPT port not found... Parallel port /dev/lp0 not foud also. After that i modified source RXTXCommDriver.java, registerScannedPorts if (osName.equals("Linux") { String[] temp = { "lp", // linux printer port "usblp" <====================== add this }; CandidatePortPrefixes = temp; } else if (osName.equals("FreeBSD")) { But /dev/usblp0 not found anyway. After that i modified registerValidPorts if (osName.equals("Solaris") || osName.equals("SunOS")) { checkSolaris(PortName, PortType); } else { if (PortType==CommPortIdentifier.PORT_PARALLEL) <<<< i.e. port type is parallel - don't execute testRead CommPortIdentifier.addPortName( PortName,PortType,this); <<<< else if (testRead(PortName, PortType)) CommPortIdentifier.addPortName( PortName,PortType,this); } result: /dev/ttyS2 - Serial /dev/ttyS1 - Serial /dev/ttyS0 - Serial /dev/usblp0 - Parallel /dev/lp0 - Parallel I think, what native testRead incorrectly defines presence of parallel port. I think that presence parallel port can be checked up so: int status=0; if (ioctl(handle, LPGETSTATUS, &status)<0) // port is not exist or it is not parallel port else // port is parallel! After that i execute program: CommPortIdentifier id = CommPortIdentifier.getPortIdentifier("/dev/usblp0"); ParallelPort port = (ParallelPort)id.open("iam", 5000); String str = "12313212312313121231321231231312"; port.getOutputStream().write(str.getBytes()); port.close(); Result: RXTXCommDriver:getCommPort(/dev/usblp0,2) LPRPort:LPRPort(/dev/usblp0) Port /dev/usblp0 in use by another application gnu.io.PortInUseException: Unknown Linux Application linux-fceg:/var/log # lsof | grep /dev/usb I.e. port is not use. Similar result at use /dev/lp0 How i can use parallel ports in my program? PS: Sorry for my english :) From tjarvi at qbang.org Sun Dec 9 00:03:51 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 00:03:51 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475B27F7.5040500@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: On Sat, 8 Dec 2007, U. George wrote: >>> But I am not talking about multiple threads reading from the same >>> port. I am dealing with a case in which one thread is reading from the >>> port, and another wants to close the port. >> > So I looked at the RXTX code ( close(), read() ) ( is that what u were > trying to point out ? ) and it seems that a close() may not close. If > there is heavy reading, then maybe close wont happen at all. > > Not sure why read is synchronized. If someone wants to read - > uncoordinated, then that his option! > But the read() and the close() does not appear to have a strong method > of synchronization ( close should set a flag, that would cause any > further I/O requests to throw an exception ). > > On would think that a close() would also prevent any further write() > operations. But it does not. It also does not appear to wait for the > write( b[] ) to complete ( in case the array has to be written out in > chunks bec the kernel buffer is full. ) > Hi George, The code may not look conventional because I wasnt looking at other code at the time. It does do close to what you expect. The code got there the hard way though. close sets the fd to 0 which should throw exceptions if you try IO. while( IOLocked > 0 ) should delay close while reading and writing are in progress. In write(b[]) the following code can be found (comments added): // throw exception if closed. if ( fd == 0 ) throw new IOException(); // prevent closing while writing. IOLocked++; // Ensure the event thread is not being setup. ie // open() waitForTheNativeCodeSilly(); read() has the same logic (deleting some code for clairity) if ( fd == 0 ) throw new IOException(); IOLocked++; waitForTheNativeCodeSilly(); The close(): (for clairity just the code that we care about here:) while( IOLocked > 0 ) { sleep() } removeEventListener(); nativeClose( this.name ); fd = 0; -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 03:35:47 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 05:35:47 -0500 Subject: [Rxtx] ParallelPort&RXTX - it works in Linux? In-Reply-To: <475BA7C9.6090900@gmail.com> References: <475BA7C9.6090900@gmail.com> Message-ID: <475BC503.7010708@gatworks.com> > > linux-fceg:/var/log # ll /dev/usb* > lrwxrwxrwx 1 root root 7 Dec 9 08:56 /dev/usblp0 -> /dev/usb/lp0 I suppose this is your first issue i would have expected a /dev/usblp0 ->/dev/lp1 ( since most machines have a /dev/lp0 ) > > result: > /dev/ttyS2 - Serial > /dev/ttyS1 - Serial > /dev/ttyS0 - Serial > Virtual LPT port not found... Parallel port /dev/lp0 not foud also. thats bec lp0 its in /dev/usb ! > > LPRPort:LPRPort(/dev/usblp0) > Port /dev/usblp0 in use by another application > gnu.io.PortInUseException: Unknown Linux Application rxtx code: int fd = open( filename, O_RDWR | O_NONBLOCK ); rxtx appears to want to be able to open the device for reading AND writing. I suspect permission failure. 1) anyway have a symbolic pointer from /dev/usb/usblp0 to /dev/lp0 2) change permissions to be RW for you group or owner. From netbeans at gatworks.com Sun Dec 9 04:44:35 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 06:44:35 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: <475BD523.3000900@gatworks.com> > close sets the fd to 0 which should throw exceptions if you try IO. Setting fd to 0 appears to be the last step in rxtx-close. It should be the first step, as a mutex to prevent any further I/O to the channel. With hyperthreads, quad cpu's, other threads can be simultaneously ( in real time ) executing reads & writes & other things. > > while( IOLocked > 0 ) should delay close while reading and writing are > in progress. Yes, but there is nothing there to prevent any further user I/O. You could have a bunch of threads continue to read & write, and keep IOLock > 0 for some time. Even if it did reach IOLock reached 0, there is still the possibility of some thread upping IOLock inbetween. > > In write(b[]) the following code can be found (comments added): > > // throw exception if closed. > if ( fd == 0 ) throw new IOException(); > // prevent closing while writing. Where is the "prevent further writing while closing" ? > > (for clairity just the code that we care about here:) > > while( IOLocked > 0 ) > { sleep() } this can take a long time to process. And defeats the purpose of a close() at time x. Because at time x+1, any further user requests to that file descriptor should have failed. One also has to ask why is the user program still reading or writing after having the close() called? But that is for the user to figure out. The orig question posed was to have a multi cpu, and 2 java threads. 1 thread was reading, while the other was ( attempting to ) closeing. probably something like this should be done: public close() { synchonize( eis ) { we_are_closing_up = true; while ( IOLock > 0 ) sleep( 100ms ); } native_close(); fd = 0; } we_are_closing_up = false; } public write() { if ( we_are_closing_up ) synchronize( eis ) { ; } if ( fd == 0 ) throw ( ..... IOLock++; ...... this is also not perfect. There is the possibility that a close could happen after the test, and before the IOLock++ From beat.arnet at gmail.com Sun Dec 9 05:44:23 2007 From: beat.arnet at gmail.com (Beat Arnet) Date: Sun, 09 Dec 2007 07:44:23 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475BE327.9010709@gmail.com> Thanks to all for responding to my original question! From what I hear, we now suspect that some improvements in RXTX might be necessary to make the code 100% thread safe. I would be happy to help, but I fear that I might not quite have the necessary training/skills. Maybe with some guidance I could give it a try. Since there has been no official release since 2.1.7, I am also wondering where I should start in the trunk so that I can be sure that all valid bug fixes that have been submitted sine 2.1.7 are included. However, I would also like to find out if there is something short-term that I can do in my application to avoid dead-locks on dual core machines, before RXTX is fixed. After Daniel's response, I synchronized all RXTXPort accesses, but I have still some crashes being reported from the field, albeit much less (and possibly unrelated?). Should I setup my code such that all accesses to the serial port happen in one unique thread? Would this prevent the problems that are described below? Any further guidance from the group would be appreciated. Regards, Beat U. George wrote: >> close sets the fd to 0 which should throw exceptions if you try IO. >> > Setting fd to 0 appears to be the last step in rxtx-close. It should be > the first step, as a mutex to prevent any further I/O to the channel. > With hyperthreads, quad cpu's, other threads can be simultaneously ( in > real time ) executing reads & writes & other things. > > > >> while( IOLocked > 0 ) should delay close while reading and writing are >> in progress. >> > Yes, but there is nothing there to prevent any further user I/O. You > could have a bunch of threads continue to read & write, and keep IOLock > > 0 for some time. > Even if it did reach IOLock reached 0, there is still the possibility of > some thread upping IOLock inbetween. > >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. >> > Where is the "prevent further writing while closing" ? > >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } >> > this can take a long time to process. And defeats the purpose of a > close() at time x. Because at time x+1, any further user requests to > that file descriptor should have failed. > One also has to ask why is the user program still reading or writing > after having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/6b16e64b/attachment-0007.html From tjarvi at qbang.org Sun Dec 9 11:01:00 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 11:01:00 -0700 (MST) Subject: [Rxtx] Dual Core Problem In-Reply-To: <475BD523.3000900@gatworks.com> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: On Sun, 9 Dec 2007, U. George wrote: > >> close sets the fd to 0 which should throw exceptions if you try IO. > Setting fd to 0 appears to be the last step in rxtx-close. It should be the > first step, as a mutex to prevent any further I/O to the channel. With > hyperthreads, quad cpu's, other threads can be simultaneously ( in real time > ) executing reads & writes & other things. > > >> >> while( IOLocked > 0 ) should delay close while reading and writing are in >> progress. > Yes, but there is nothing there to prevent any further user I/O. You could > have a bunch of threads continue to read & write, and keep IOLock > 0 for > some time. > Even if it did reach IOLock reached 0, there is still the possibility of some > thread upping IOLock inbetween. >> >> In write(b[]) the following code can be found (comments added): >> >> // throw exception if closed. >> if ( fd == 0 ) throw new IOException(); >> // prevent closing while writing. > Where is the "prevent further writing while closing" ? >> >> (for clairity just the code that we care about here:) >> >> while( IOLocked > 0 ) >> { sleep() } > this can take a long time to process. And defeats the purpose of a close() at > time x. Because at time x+1, any further user requests to that file > descriptor should have failed. > One also has to ask why is the user program still reading or writing after > having the close() called? But that is for the user to figure out. > > > > The orig question posed was to have a multi cpu, and 2 java threads. 1 thread > was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could happen > after the test, and before the IOLock++ > There are two questions in the back of my mind. The first is I'd like to see some form of documentation in the Java API that says this is the right behavior. Anything from file IO to network sockets. The second is that we are dealing with perhaps the slowest reads and writes out there. I'd anticipate some downstream impact (incompatability) with people using the current implementation. At least at first, a change like this should be something people opt into via preferences or other means. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 12:17:15 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 14:17:15 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C3F3B.9050003@gatworks.com> > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. ?? I'm not sure what behavior your are expecting the JAVA docs to explain? I'd be more interested in the OS docs that will/could explain the interaction of threads and the sequencing of I/O operations amongst active cpu instruction pipelines. > > The second is that we are dealing with perhaps the slowest reads and > writes out there. I'd anticipate some downstream impact > (incompatability) with people using the current implementation. At > least at first, a change like this should be something people opt into > via preferences or other means. u mean there are folks that continue to read & write even though they also issued a (premature) close ? I am not aware of any OS that behaves like that. Or allows that. Yes, but if you will notice, the the speed of USB devices, that are made to behave like serial, or parallel devices, are very-very fast. A 500ms sleep is forever on some USB devices. BTW: Since JAVA source went public, sorta, did java publish the commapi source? BTW#2:Your mail to 'Rxtx' with the subject If not DEBUGing, remove useless calls to report() et al Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 46243 bytes with a limit of 40 KB From netbeans at gatworks.com Sun Dec 9 13:00:09 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 15:00:09 -0500 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> <475BD523.3000900@gatworks.com> Message-ID: <475C4949.5060109@gatworks.com> > > There are two questions in the back of my mind. The first is I'd like > to see some form of documentation in the Java API that says this is the > right behavior. Anything from file IO to network sockets. from Class CommPort: After a communications port has been identified and opened it can be configured with the methods in the low-level classes like SerialPort and ParallelPort. Then an IO stream can be opend for reading and writing data. Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown. From dwippermann at gmx.net Sun Dec 9 13:36:28 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:36:28 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> Message-ID: Hi all, > If you can you should assign the responsibility of closing the port > to the one > handling the port. The other thread should simply be telling the > handling thread > that it should close the port. Threads are like people, in that if > you give them > conflicting instructions all hell breaks loose. For example of what > I think you > should do: > yes, that you be the common way if I had full control over the thread. But the thread is implemented and started by RXTX, I only get event through my listener. How should the listener be able to close the port if no event is triggered? Can I wake up the RXTX thread to send a dummy event to trigger the close from inside the listener? Daniel From dwippermann at gmx.net Sun Dec 9 13:55:37 2007 From: dwippermann at gmx.net (Daniel Wippermann) Date: Sun, 9 Dec 2007 21:55:37 +0100 Subject: [Rxtx] Dual Core Problem In-Reply-To: References: <460801A4097E3D4CA04CC64EE648584803CC8D5F@ism-mail03.corp.ad.wrs.com> <47599422.4020003@gatworks.com> <0361E8F9-0A65-4D91-AE34-45877CF51F35@sympatico.ca> <475B27F7.5040500@gatworks.com> Message-ID: And hi once more, > The orig question posed was to have a multi cpu, and 2 java threads. 1 > thread was reading, while the other was ( attempting to ) closeing. > > > probably something like this should be done: > > public close() { > synchonize( eis ) { > we_are_closing_up = true; > while ( IOLock > 0 ) > sleep( 100ms ); > } > native_close(); > fd = 0; > } > we_are_closing_up = false; > } > > public write() { > if ( we_are_closing_up ) > synchronize( eis ) { ; } > if ( fd == 0 ) throw ( ..... > IOLock++; > ...... > > > this is also not perfect. There is the possibility that a close could > happen after the test, and before the IOLock++ Thats the reason why I encapsulated all access in synchronized blocks using one mutex. You simply have no problem with "after ... , but before..." anymore :) One other problem I see is the use of the ++/-- operators on a variable that can be accessed by mutliple threads in parallel. I'll run a short test tomorrow on my office machine, but I assume that its read-modify-write behaviour might bring up a collision like: IOLocked = 100, both thread are running in different CPUs, but due to timing arrive at the "IOLocked--" nearly simultaneously CPU 1: reads variable to register => register = 100 CPU 2: doing something else -- CPU 1: decrements register => register = 99 CPU 2: reads variable to register => register = 100 -- CPU 1: writes register to variable => variable = 99 CPU 2: decrements register => register = 99 -- CPU 1: doing something else CPU 2: writes register to variable => variable = 99 It should have decremented twice, but it didn't... Thats a common situtation where locking is needed: modify the same variable from different threads without synchonization is hell :) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20071209/4bd9d474/attachment-0006.html From netbeans at gatworks.com Thu Dec 6 04:14:53 2007 From: netbeans at gatworks.com (U. George) Date: Thu, 06 Dec 2007 06:14:53 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al Message-ID: <4757D9AD.2080305@gatworks.com> For the most part the report() calls from everywhere is usefull in debugging whats happening within rxtx. BUT if you are not debugging, then it is just wasted CPU cycles. That also includes the sprintf's sprinkled here and there. I placed the DEBUG code ( SerialImp.c ) under the #ifdef DEBUG . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: a Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20071206/92c448eb/attachment-0006.pl From tjarvi at qbang.org Sun Dec 9 19:15:44 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19:15:44 -0700 (MST) Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: <4757D9AD.2080305@gatworks.com> References: <4757D9AD.2080305@gatworks.com> Message-ID: This looks OK to me George. Just two issues. make_message is probably copyrighted by the Free Software Foundation. It is probably easier to recode it than deal with the minor potential issues. The only other minor issue is that commenting out code isn't really better than deleting it in the long run. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun Dec 9 19:35:41 2007 From: netbeans at gatworks.com (U. George) Date: Sun, 09 Dec 2007 21:35:41 -0500 Subject: [Rxtx] If not DEBUGing, remove useless calls to report() et al In-Reply-To: References: <4757D9AD.2080305@gatworks.com> Message-ID: <475CA5FD.6050801@gatworks.com> Trent Jarvi wrote: > > This looks OK to me George. Just two issues. > > make_message is probably copyrighted by the Free Software Foundation. > It is probably easier to recode it than deal with the minor potential > issues. code u refer to is not used. I'm not too sure if "all" cc/libs can handle the particular var-args scheme. So if blows up, then that becomes an issue, but not harmfull for anybody's run. I did want to use it to do: REPORT("FIONREAD failed with error %s\n", strerror( errno )); or more recently REPORT( "Failed to open device %s. error = %s\n", name, strerror( errno )); Since u PORT this to other machines, its not clear if var-args works everywhere the same way. u got any notion? > > The only other minor issue is that commenting out code isn't really > better than deleting it in the long run. > Sorta, sorta not. For short run ( in the heading of small changes ) it looks just like all the other items (historically) commented out, but not yet removed :) More things to clean up for the long run i guess. From tjarvi at qbang.org Sun Dec 9 19:47:37 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Dec 2007 19