[dev] channel construct for inter-thread communication in C programs

2010-09-09 Thread Mate Nagy
Hello all,

I guess I can't get enough of the punishment I always get in these
threads. Announcing project:

http://repo.hu/projects/cchan/

'This is a small library that implements a channel construct for
inter-thread communication in C programs. '

This is a very small and simple lib that does one thing only.
It uses mutexes and conds for synchronization; it is interfaced to the
thread API using a very thin .h file with macros. It would be probably
quite easy to port it to use other thread APIs. Currently it supports
pthreads and SDL threads.

Doesn't use C99 or gcc-specific features, hopefully.

Future development: would be nice to implement a select() operation for
listening on multiple channels at once; would probably also be very
complicated.

Regards,
 Mate

PS. I'm fully aware that Plan 9 has this functionality built in. Not
interested in you should use plan9 and/or plan9 portability libs mails
thanx



Re: [dev] channel construct for inter-thread communication in C programs

2010-09-09 Thread Corey Thomasson
libtask [ http://swtch.com/libtask/ ] implements something
similar/same; however, it's a coroutine lib and I'm pretty sure it
will not work with multiple threads.

However, it does have something like a select() for channels, see the
Alt structure and associated methods, IIRC the implementation is
fairly simple.

On 9 September 2010 07:21, Mate Nagy mn...@port70.net wrote:
 Hello all,

 I guess I can't get enough of the punishment I always get in these
 threads. Announcing project:

 http://repo.hu/projects/cchan/

 'This is a small library that implements a channel construct for
 inter-thread communication in C programs. '

 This is a very small and simple lib that does one thing only.
 It uses mutexes and conds for synchronization; it is interfaced to the
 thread API using a very thin .h file with macros. It would be probably
 quite easy to port it to use other thread APIs. Currently it supports
 pthreads and SDL threads.

 Doesn't use C99 or gcc-specific features, hopefully.

 Future development: would be nice to implement a select() operation for
 listening on multiple channels at once; would probably also be very
 complicated.

 Regards,
  Mate

 PS. I'm fully aware that Plan 9 has this functionality built in. Not
 interested in you should use plan9 and/or plan9 portability libs mails
 thanx





Re: [dev] channel construct for inter-thread communication in C programs

2010-09-09 Thread Corey Thomasson
I was only referring to the channels, not the entire library. I
pointed it out more as a potential jumpstart for implementing a
select(), etc. I wasn't trying to say cchan was redundant.

On 9 September 2010 08:29, Szabolcs Nagy n...@port70.net wrote:

 that's not similar/same

 the entire point of the excersise is to do messaging when you need to
 exploit modern multicore buzzword compliant architectures

 libtask does no such thing
 libthread does i guess






Re: [dev] channel construct for inter-thread communication in C programs

2010-09-09 Thread Mate Nagy
On Thu, Sep 09, 2010 at 08:42:43AM -0400, Corey Thomasson wrote:
 I was only referring to the channels, not the entire library. I
 pointed it out more as a potential jumpstart for implementing a
 select(), etc. I wasn't trying to say cchan was redundant.
libtask is a good pointer and looks nice (i remember it being mentioned
in this ML before).

unfortunately, I believe the major difficulties with implementing
select() come from the preemptively multi-threaded nature of the
environment...

regards,
 Mate



Re: [dev] channel construct for inter-thread communication in C programs

2010-09-09 Thread Ethan Grammatikidis


On 9 Sep 2010, at 2:07 pm, Mate Nagy wrote:


On Thu, Sep 09, 2010 at 08:42:43AM -0400, Corey Thomasson wrote:

I was only referring to the channels, not the entire library. I
pointed it out more as a potential jumpstart for implementing a
select(), etc. I wasn't trying to say cchan was redundant.
libtask is a good pointer and looks nice (i remember it being  
mentioned

in this ML before).

unfortunately, I believe the major difficulties with implementing
select() come from the preemptively multi-threaded nature of the
environment...


Am I right in thinking if you can spawn threads freely you don't  
really need select()? I got that idea somewhere, but I'm a bit hazy  
on the logic behind it.