Click here to Skip to main content
15,904,346 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I want to use a I/O completion port to load up plugins and process plugins for my program.

The problem is that when you create the Io Completion port and try to associate a plugin with according to msdn you need to give it handle since i only have the path to the plugins (i then load them with loadlibrary) i cant do this

how can i use I/O completion ports in this context? (i.e i dont have a file or sockets i just need throw)


In short i have lots of plugins i need to load dynamically so instead of using a 1 thread per plugin model i need to use something scalable like io completion ports but i dont know how associate a plugin with the completion port (before it is loaded every plugin is represented by a structure)
Posted
Updated 16-May-11 23:43pm
v3

Have you tried using WaitForSingleObject(hUploadHandle)
or something like that?
 
Share this answer
 
Comments
Olivier Levrey 17-May-11 8:28am    
I agree. 5.
What is wrong with using threads? For me there are 2 options:

1- You load your plugins one by one in 1 thread and show the progression in a progress bar or something.
2- You load your plugins in separate threads, and as soon as a thread finishes (so as soon as a plugin is loaded), you update the progression bar.

As Debijyoti told you, you can use WaitForSingleObject or WaitForMultipleObjects on the different threads to know when they finish.

--------------------

As Kurt Degiorgio noticed, this solution is not suitable for a big numbers of plugins. I would then choose a pool of threads: you can create let's say 10 threads, each of them will load several plugins, and so on.
 
Share this answer
 
v3
Comments
hakz.code 17-May-11 8:37am    
I agree
Kurt Degiorgio 17-May-11 8:47am    
Reason for 4: That will work, but what if the op has lets say 1k of plugins? check my answer pls :)
Olivier Levrey 17-May-11 8:52am    
You are right, this solution is not suitable for a big number of plugins. I would probably rather use a pool of threads instead to make sure I don't exceed the limit.
Kurt Degiorgio 17-May-11 8:59am    
yep :) in fact iocomplition port is thread pool manged by OS = SUPER FAST, (its used by web servers to handle requests) it is also very scalable :)
As previous posts suggested if the number of threads needed is less then 64 then you should implement it using the normal threading model but if the number of threads goes above 64 then this becomes very inefficient.

waitformultpleobjects can only wait on a max of 64 objects plus you will be wasting lots of cpu cycles on context switch's as such on windows platforms completion ports are the way to go in this scenario.

first - go back and read about io compilation ports (check MSDN)

second - unlike in normal scenario where the OS will insert work items into the io compilation port(they are called i/o packets)you need to manually insert them using the provided functions (again check MSDN)

EDIT - here are the functions you need to look at:

http://msdn.microsoft.com/en-us/library/aa364986%28v=vs.85%29.aspx[^] - get an item from the completion port

http://msdn.microsoft.com/en-us/library/aa365458%28v=vs.85%29.aspx[^] - insert an item into the io completion port
 
Share this answer
 
v3
Comments
Olivier Levrey 17-May-11 8:51am    
Ok good but you didn't really help OP there. You just told him to read MSDN...
Kurt Degiorgio 17-May-11 9:03am    
I apologize, forget to add the links :(

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900