Cygwin and fork
Moderator: Moderator Team
Cygwin and fork
Hi,
I am trying to create an imagectn under Windows that is capable of handling multiple associations at a time. As far as I understood this is not supported in an executable created with MS Visual Studio. So my idea was to built a version with cygwin.
Since cygwin provides a UNIX/Linux like environment, including the fork system call, I was hoping that this could run out-of-the box. Unfortunately it did not. Instead I get some errors like:
dcdatset.cc, LINE 252:DcmDataset::read: At End: errorFlag = I/O suspension or premature end of stream
when trying to push a dicom file via movescu. According to my analysis, this happens when trying to read the data from the socket connection. I don't think this is related to multi-prosessing since it also happens when I start "imagectn -s".
Has anyone seen this before, or even better, an idea how to fix this?
BTW my environment is WindowsXP SP2, with cygwin updated yesterday and dcmtk-3.5.3. I tried both, gcc-3.3.3 and gcc-3.4.4.1. No difference.
Thanks in advance
mdheuler.
I am trying to create an imagectn under Windows that is capable of handling multiple associations at a time. As far as I understood this is not supported in an executable created with MS Visual Studio. So my idea was to built a version with cygwin.
Since cygwin provides a UNIX/Linux like environment, including the fork system call, I was hoping that this could run out-of-the box. Unfortunately it did not. Instead I get some errors like:
dcdatset.cc, LINE 252:DcmDataset::read: At End: errorFlag = I/O suspension or premature end of stream
when trying to push a dicom file via movescu. According to my analysis, this happens when trying to read the data from the socket connection. I don't think this is related to multi-prosessing since it also happens when I start "imagectn -s".
Has anyone seen this before, or even better, an idea how to fix this?
BTW my environment is WindowsXP SP2, with cygwin updated yesterday and dcmtk-3.5.3. I tried both, gcc-3.3.3 and gcc-3.4.4.1. No difference.
Thanks in advance
mdheuler.
Instead of using fork(), I have had good results on Windows with the following methodology:
- The main thread loops waiting for associations
- If it receives an association request and successfully negotiates, then the association is accepted.
- A new thread is spawned to handle the accepted association (pass the association structure pointer as a thread parameter)
This google groups thread says much the same (and it' where I got my inspiration from)
http://groups-beta.google.com/group/com ... 7ef47f880c
HTH!
- The main thread loops waiting for associations
- If it receives an association request and successfully negotiates, then the association is accepted.
- A new thread is spawned to handle the accepted association (pass the association structure pointer as a thread parameter)
This google groups thread says much the same (and it' where I got my inspiration from)
http://groups-beta.google.com/group/com ... 7ef47f880c
HTH!
-
- OFFIS DICOM Team
- Posts: 1493
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
The Cygwin port has never really intensively been tested - you may have found a specific bug that only shows on Cygwin, possible due to a difference in behaviour of some system function emulation. Looks like this requires some time and a good debugger, but currently we won't be able to support you with that, due to resource limitations.
-
- Posts: 13
- Joined: Tue, 2005-06-28, 16:48
I have been under the impression that the network code in dcmtk was not multi-thread safe. We have been investigating other toolkits such as Leadtools lately because we are looking to port all of our systems to Windows. (much better luck walking other non-technical people through troubleshooting at 3 a.m.)
FAQ: viewtopic.php?t=24
Our current routing software is based on DCMTK 3.5.2 and runs on Linux. The code is already set up in a way that it would be very simple to replace the fork()s and it will already compile and run on Windows in a single association mode (much like imagectn). Can this be confirmed that it is reasonably safe to multi-thread DCMTK's networking code? Any got'chas?
This would make me the hero of the hour if we didn't have to spend $7500 to $10000 on Leadtools or Merge.
FAQ: viewtopic.php?t=24
Our current routing software is based on DCMTK 3.5.2 and runs on Linux. The code is already set up in a way that it would be very simple to replace the fork()s and it will already compile and run on Windows in a single association mode (much like imagectn). Can this be confirmed that it is reasonably safe to multi-thread DCMTK's networking code? Any got'chas?
This would make me the hero of the hour if we didn't have to spend $7500 to $10000 on Leadtools or Merge.
My experience (which should certainly not be taken as gospel) is that DCMTK can be made thread safe when using it in an SCP role (see above), but that it is not, in general, thread-safe when using it in an SCU role.
I say this because I had some SCU code running which handled multiple concurrent C-STORE operations, and cleaning up terminated jobs appeared to stomp all over something in the networking code, with the obvious dire consequences for associations that are still active.
As I said, I have had reasonable success with DCMTK on Windows in an SCP role, but further testing is needed before I can say for sure.
Without being disparaging to Joerg and the team (who have done a fantastic job), I have been looking at the UC Davis code as well, because the Conquest server (which in turn is built on Mark Oskin's microPACS codebase) is based on this code and it seems to handle multiple concurrent associations with aplomb. The biggest problem with this code is that it is no longer in active development at UC Davis, but the Conquest project people are doing a certain amount of work on it.
Sorry if this has gone a bit off topic!
I say this because I had some SCU code running which handled multiple concurrent C-STORE operations, and cleaning up terminated jobs appeared to stomp all over something in the networking code, with the obvious dire consequences for associations that are still active.
As I said, I have had reasonable success with DCMTK on Windows in an SCP role, but further testing is needed before I can say for sure.
Without being disparaging to Joerg and the team (who have done a fantastic job), I have been looking at the UC Davis code as well, because the Conquest server (which in turn is built on Mark Oskin's microPACS codebase) is based on this code and it seems to handle multiple concurrent associations with aplomb. The biggest problem with this code is that it is no longer in active development at UC Davis, but the Conquest project people are doing a certain amount of work on it.
Sorry if this has gone a bit off topic!
-
- OFFIS DICOM Team
- Posts: 1493
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
The FAQ is still up to date: the network module is not safe for multi-thread applications, neither for SCU nor for SCP usage. However, making the network module (as of DCMTK 3.5.3 which already has certain improvements over 3.5.2) thread-safe for the Win32 platform would be almost trivial - there are only a few global/static objects that would need to be mutex protected. A complete solution also covering the Posix platforms would be much more difficult since one would have to replace all non MT-safe system functions (gethostbyname etc.) by the corresponding _r variants, i.e. write a lot of additional configure tests and check which of the non-Posix functions used by the toolkit are MT safe on which platform (Single Unix, BSD, ...) - all of this is a non-issue on Win32 since the libc is MT safe there when compiled for multi-thread operation.
-
- Posts: 13
- Joined: Tue, 2005-06-28, 16:48
Are there any plans to make DCMTK multi-thread safe? I don't mind us spending a few days working to make it multi-thread safe, but I hate working on things that we will have to redo next release. The DCMTK team would be more than welcome to use our patches (directly or indirectly). At the same time I feel like they will not be usable for you as you have a private CVS and have most likely already made changes from the 3.5.3 release.
-
- OFFIS DICOM Team
- Posts: 1493
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Who is online
Users browsing this forum: No registered users and 1 guest