A multithreaded chatbot? Idea...

[option]

I've been learning how to code multithreaded apps in school, and it got me thinking about my plans of creating a chatbot.

Would there be any sense in doing something like this? I was thinking about creating an option to spawn a number of different connection sequences, opening up one thread per sequence?

Or maybe one thread per major function in my program?

What do you guys think

[RealityRipple]

My bot Entelechy already makes full use of threading and asynchronous events. Every tab (profile) has its own main worker thread, every incoming packet gets its own thread for parsing and handling. It makes things pretty smooth.

[MyndFyre]

BN# is intrinsically multi-threaded as well.

[option]

Damn, and here I am thinking I'm an innovator. (Jk)

I'm still torn on whether to write my bot in c, or take an oo approach and write it in c++. If I were to write this in c++, would it make sense to code a thread spawner object (which stored pointers to various functions as parameters as its local vars? (A built in jump-table, so to speak).

In school, I'm learning multithreading with posix threads. Are they optimal for coding multithreaded apps, or is there a better c/c++ convention?

[MyndFyre]

I'm still torn on whether to write my bot in c, or take an oo approach and write it in c++. If I were to write this in c++, would it make sense to code a thread spawner object (which stored pointers to various functions as parameters as its local vars? (A built in jump-table, so to speak).

In school, I'm learning multithreading with posix threads. Are they optimal for coding multithreaded apps, or is there a better c/c++ convention?

You can take an OO approach while using C.  The only thing you can't do with C that you can do with C++ intrinsically is vtables, but arguably you can do those too with jump tables.

BN# uses a jump-table kind of approach for dispatching packet-parsing.  That's not a separate thread, though.

I'm surprised that you're learning posix threads, because threads aren't really POSIX.  I mean, you can do them of course, but on *nix systems, threading is usually considered expensive, whereas forking a new process is generally considered cheap.  (The opposite is true on Windows; threading is inexpensive whereas starting a new process is expensive).  I guess I also did some POSIX threading in my operating systems class a few years ago, but it wasn't really for the purposes of learning threads, but mutexes and semaphores.

Building factory objects is, IMO, a good thing if you have a reason to use virtual classes.  But if you're wrapping every "new ThreadRunner" with "ThreadRunnerFactory::Create()" there's not much gained.

[option]

Why would I take an OO approach using C, when I can have classes and all of the other "way more OO" conventions that C++ offers? I've been using C quite often because that's what they taught us posix threads in. How can I write OO code in C? For class, I've been creating variables (that would be class variables), and using them in functions (defined in other files), that would be the class functions. Is that what you mean?

What's a "managed library" btw, saw it in your sig.

I develop on Windows, but I have a ported posix thread library that I use on windows for my school projects and stuff. Would it be weird to develop my threaded functions using pthreads, even though I'm developing on Windows?

Like - if I said fuck it right now, and started coding my chatbot in c/c++ and it used pthreads - would such be "unconventional"? What sort of thread library do you use in your work?

EDIT:

Also, I don't want to use winsock. I'd optimally like my bnet chat client to run on the UNIX architecture as well. Is C++ and ACE my best bet?