DLL creation for DCMNet
Moderator: Moderator Team
DLL creation for DCMNet
Hello...
Just a quick question... Was there any attempt to compile the dcmnet library into a DLL?
The whole FSM is statically defined there and I wonder, given prior experience I had with this, if it is possible at all to build a reliable DLL for DCMNET.
Thank you.
~~Razvan
Just a quick question... Was there any attempt to compile the dcmnet library into a DLL?
The whole FSM is statically defined there and I wonder, given prior experience I had with this, if it is possible at all to build a reliable DLL for DCMNET.
Thank you.
~~Razvan
Thanks for your reply. Have you tried running multiple SCU's at the same time?hamlet wrote:Maybe you could it.
I writed a atl/com include SCU function, like echoscu, findscu, storescu and movescu.
It works fine, I think.
It seems to me that the code in DCMNET is not re-entrant and that's my major concern.
~~Razvan
yes, I try to use multiple SCUs to Q/R a server at the same time.
You could run multiple SCUs on different PCs. I think it's ok.
But maybe you would have problems to run multiple SCUs on the same time, especially you run multiple movescu (I think movescu will open network port to listen incoming data, when aother program open the same port will fail)
You could run multiple SCUs on different PCs. I think it's ok.
But maybe you would have problems to run multiple SCUs on the same time, especially you run multiple movescu (I think movescu will open network port to listen incoming data, when aother program open the same port will fail)
The problem you describe with movescu is accurate but it can be resolved with an intervention in the movescu design, allowing it to accept multiple requests by selecting different ports. But that's anyther story, I ran into trouble while using multiple programs running storeSCU clients with StoreSCU code implemented inside a DLL which was at its turn statically linked to offis.
I am not excluding the possibility that it is my wrongdoing somewhere (I had a headscratching time when I forgot that storeSCP.exe I was using is single threaded during past test sessions and was wondering why multiple storeSCU were treated sequentially
) but I would like to hear from any of the OFFIS guys whether the DCMNET library can or cannot be used safely in multi-threaded environmets.
Is this the non-reentrancy of the code the reason why OFFIS comes in static libraries instead of DLLs?
Can anybody please clarify this? Is this a FAQ that I can't find? I would appreciate any hints.
I am not excluding the possibility that it is my wrongdoing somewhere (I had a headscratching time when I forgot that storeSCP.exe I was using is single threaded during past test sessions and was wondering why multiple storeSCU were treated sequentially

Is this the non-reentrancy of the code the reason why OFFIS comes in static libraries instead of DLLs?
Can anybody please clarify this? Is this a FAQ that I can't find? I would appreciate any hints.
Actually, I did test it using the last free Efilm 1.5.3, after realizing the storeSCP trouble.hamlet wrote:I think storescu should be ok in multi-threaded environmet. Do you try to test storescu using imagectn?
My test servers are imagectn(OFFIS), conquestServer(UCDCM). They are free.
PaceOne is another free server. But it is a little hard to set up.
But that succesfull test was done _after_ separating the whole dcmnet code from any DLL I used so all the storeSCU's there were actually statically linked to dcmnet, posing absolutely no multi-threading/processing issues.
However, even if storeSCP is single threaded, there is no reason for several storeSCUs attempting to connect to it to start throwing state-machine errors.
Or is it??
~~Razvan
OK, I am answering again my own questions. I was browsing the FAQ looking for "multithreading" but when I finally got a really close and careful look at the FAQ I found what I was looking for under the "thread-safe" section at viewtopic.php?t=24.razvanux wrote:Actually, I did test it using the last free Efilm 1.5.3, after realizing the storeSCP trouble.hamlet wrote:I think storescu should be ok in multi-threaded environmet. Do you try to test storescu using imagectn?
My test servers are imagectn(OFFIS), conquestServer(UCDCM). They are free.
PaceOne is another free server. But it is a little hard to set up.
But that succesfull test was done _after_ separating the whole dcmnet code from any DLL I used so all the storeSCU's there were actually statically linked to dcmnet, posing absolutely no multi-threading/processing issues.
However, even if storeSCP is single threaded, there is no reason for several storeSCUs attempting to connect to it to start throwing state-machine errors.
Or is it??
~~Razvan
Thanks to Hamlet for trying to help.
Who is online
Users browsing this forum: Ahrefs [Bot] and 0 guests