Winsock CreateProces()

Started by
11 comments, last by Nik02 18 years, 7 months ago
I'm try to learn winsock but I don't know how the CreateProces() function works. In the tutorial im using they use fork() which isn't explained either but they said you need to use CreateProces() for windows. Anyway can someone please give me some information about this function? How it works and how to use it etc. Thanks, Toadhead
Advertisement
CreateProcess function loads and runs an executable image (program), and returns a handle to it so that the parent process (that called CreateProcess) can wait, interrupt or otherwise manipulate it.

While I'm not a Mac expert, I think that fork function does more or less the same thing.

Neither of these methods have direct meaning in socket programming.

EDIT: Fork() makes a copy of the current process, instead of running an arbitrary executable like CreateProcess.

MSDN library has info on all Windows functions.

Niko Suni

I'm guessing Toadhead is referring to this part of Beej's Guide to Network Programming:
Quote:
Finally, I hear that Windows has no fork() system call which is, unfortunately, used in some of my examples. Maybe you have to link in a POSIX library or something to get it to work, or you can use CreateProcess() instead. fork() takes no arguments, and CreateProcess() takes about 48 billion arguments.

Well, Beej wasn't kidding. CreateProcess() takes 10 aguments. You can find the function's documentation here.
Nik02, fork() and, I'm assuming, CreateProcess() are used quite a lot in network programming - for multiple listener processes, for example.
Jooleem. Get addicted.
Quote:Original post by Peregrin
Nik02, fork() and, I'm assuming, CreateProcess() are used quite a lot in network programming - for multiple listener processes, for example.


Yes, but they are not socket functions per se, and both server and client applications can very well be implemented without using either function.

I do see your point, however - CreateProcess (and I'm assuming fork also) are extensively used alongside sockets [smile]

Niko Suni

Yes I indeed used Beej's tutorial. Thanks for the info but I still don't realy get it. If you call this CreateProces 100 times does this mean you are running 100 different applications or something?? And if it opens this new process does it mean it will start executing the program again from the beginning???

I hope someone can clear it up for me since I'm a bit confused :S

Greetings,
Toadhead
Quote:Original post by Toadhead
Yes I indeed used Beej's tutorial. Thanks for the info but I still don't realy get it. If you call this CreateProces 100 times does this mean you are running 100 different applications or something?? And if it opens this new process does it mean it will start executing the program again from the beginning???

I hope someone can clear it up for me since I'm a bit confused :S

Greetings,
Toadhead


I haven't studied the said tutorial, but usually each client gets it's own server-side process or a thread. The listener loop will execute the processes and/or threads for each acceptable client, and then proceeds to listen for more connections.

It is not strictly required to spawn a new process or thread for each client, but it is very convenient and popular way of implementing a server (especially a file or data server).

And yes, if you have 100 active clients, then you practically need 100 different handlers (be it a process or a thread) to accommodate them.

Niko Suni

By the way, you might actually want to use threads instead of whole new processes when implementing the client handling procedure. Threads use far less memory, and can handle anything a standalone process can.

If you're targeting NT systems only, fibers are yet more lightweight than threads, and can do the same job.

Niko Suni

If you use a non-blocking socket you can do it in the mainloop, or you can create a blocking process.
---Yesterday is history, tomorrow is a mystery, today is a gift and that's why it's called the present.
But when I use thid CreateProces() or CreateThread were does it start executing the code for each client? I mean how does it know what piece of code it needs to run for every client?

I couldnt find this in the msdn page (its probably there but my english isnt that good so could realy understand it otherwise).

For threads, you can pass a context pointer when you create them. The thread procedure can then read from the pointer, so you can use the context to pass "parameters" to individual threads.

For processes, you can create a memory mapped file for memory sharing, or you could use pipes to transfer information between processes, or you could use environment variable blocks, or...

There's a lot of ways processes and threads can communicate with each other. You should really read up on MSDN about these techniques! There's a topic called "UNIX Application Migration Guide" which illustrates all these methods as used in real-world applications.

Niko Suni

This topic is closed to new replies.

Advertisement