Cygwin and fork

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
mdheuler
Posts: 1
Joined: Thu, 2005-06-23, 15:31

Cygwin and fork

#1 Post by mdheuler »

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.

wrgben
Posts: 20
Joined: Thu, 2005-01-06, 10:53

#2 Post by wrgben »

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!

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1493
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#3 Post by Marco Eichelberg »

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.

Colby Dillion
Posts: 13
Joined: Tue, 2005-06-28, 16:48

#4 Post by Colby Dillion »

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.

wrgben
Posts: 20
Joined: Thu, 2005-01-06, 10:53

#5 Post by wrgben »

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!

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1493
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#6 Post by Marco Eichelberg »

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.

Colby Dillion
Posts: 13
Joined: Tue, 2005-06-28, 16:48

#7 Post by Colby Dillion »

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.

wrgben
Posts: 20
Joined: Thu, 2005-01-06, 10:53

#8 Post by wrgben »

Hi Colby,

I'd be happy to colaborate with you on changes needed to make the DCMTK thread-safe for Win32. Marco, what are your thoughts on including such platform-specific changes into the general release of the toolkit?

Cheerio,

Ben

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1493
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#9 Post by Marco Eichelberg »

Win32-only changes would be OK to start with, since the changes needed for Posix are a superset of the changes needed for Win32, i.e. the work would not be wasted even if we implement a complete solution lateron.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest