Macro for pthread_create()

[James Kuyper]

How? I mean: in Linux I can simply write:

#include <pthread.h>
...
pthread_create( ... );

in OS20 I can't since it doesn't have them, so my idea is to make a
conditional compiling using a macro. Am I right?

Not necessarily. In the places where your code would call
pthread_create() on linux, what do you want your code to do on OS20?

 

[Seebs]

How? I mean: in Linux I can simply write:

#include <pthread.h>
...
pthread_create( ... );

in OS20 I can't since it doesn't have them, so my idea is to make a
conditional compiling using a macro. Am I right?

No.

A macro is a good choice if you can write a single thing which expands to
something suitable on each of your target systems. If you can't, you should
write a function for each system to provide the functionality.

The problem is that the conditional compilation doesn't do anything to solve
your actual *problem*, which is that if you don't spawn threads, the code
won't work. You need to rethink that part of the design...

-s

 

[Ben Pfaff]

A macro is a good choice if you can write a single thing which expands to
something suitable on each of your target systems. If you can't, you should
write a function for each system to provide the functionality.

I would say, instead, that a function (possibly marked "inline")
is a good choice in any case, and that a macro is a second choice
if a function cannot work.

 

[daniele.g]

Not necessarily. In the places where your code would call
pthread_create() on linux, what do you want your code to do on OS20?

It has a os20_task_create() function, which I really don't yet know how
it works, I will have to manage it in a second time.

 

[daniele.g]

Not necessarily. In the places where your code would call
pthread_create() on linux, what do you want your code to do on OS20?

task_create(), this is its syntax:

extern task_t *task_create(
task_function_t proc_func, // pointer to the task's entry point.
task_param_t proc_param, // the parameter which will be passed into proc_func.
const size_t stack_size, // required stack size for the task, in bytes.
const int priority, // task's scheduling priority.
const char *name, // the name of the task.
task_flags_t flags // start status of the task.
);

 

[James Kuyper]

task_create(), this is its syntax:

extern task_t *task_create(
task_function_t proc_func, // pointer to the task's entry point.
task_param_t proc_param, // the parameter which will be passed into proc_func.
const size_t stack_size, // required stack size for the task, in bytes.
const int priority, // task's scheduling priority.
const char *name, // the name of the task.
task_flags_t flags // start status of the task.
);

That's a fairly complicated interface; I can't imagine what your macro
would look like, but I think it would be a nightmare, as a macro.

You're basically suggesting that a macro be defined as follows:

#if SOMETHING

#include <pthread.h>
#define THREAD(func,parm) \
pthread_create(&func ## _id, NULL, func, (void *)parm)
#else

#include "something.h"
#define THREAD(func, parm) \
thread_create(????)

#endif

Note that the macro has to take the same number of parameters in both
definitions. You might need to give it more parameters, so it can pass
more on to thread_create() - but then you need to decide what
pthread_create() should do, if anything, with those additional parameters.

An easier approach would be to design your own function that wraps
whichever of the two functions is appropriate, with an interface that
allows it to make proper use of either one:

In my_thread.h:
#if SOMETHING
#include <pthread.h>
struct my_thread_info
{
// information you'll need to keep track of while using pthreads
};
#else
#include "something.h"
struct my_thread_info
{
// information you'll need while using other library
};
#endif
your_return_type my_thread_create(
struct thread_info* /* other parameters */);

in my_thread.c:

#include "my_thread.h"

my_return_type my_thread_create(
struct my_thread_info* info /*, other parameters */
)
{
#if SOMETHING
// Setup for call
pthread_create(/* arguments for call */);
// After call cleanup
#else
// Setup for call
thread_create(/* Arguments for call */);
// After call cleanup
#endif
}

You'll need a lot of flexibility to make two different threading systems
look the same, and using a function gives you a lot more flexibility
than a macro - part of the reason is the "Setup" and "After" sections
shown above.

 

[Eric Sosman]

That's a fairly complicated interface; I can't imagine what your macro
would look like, but I think it would be a nightmare, as a macro.

You're basically suggesting that a macro be defined as follows:

#if SOMETHING

#include<pthread.h>
#define THREAD(func,parm) \
pthread_create(&func ## _id, NULL, func, (void *)parm)
#else

#include "something.h"
#define THREAD(func, parm) \
thread_create(????)

#endif

Note that the macro has to take the same number of parameters in both
definitions. You might need to give it more parameters, so it can pass
more on to thread_create() - but then you need to decide what
pthread_create() should do, if anything, with those additional parameters.

An easier approach would be to design your own function that wraps
whichever of the two functions is appropriate, with an interface that
allows it to make proper use of either one:

In my_thread.h:
#if SOMETHING
#include<pthread.h>
struct my_thread_info
{
// information you'll need to keep track of while using pthreads
};
#else
#include "something.h"
struct my_thread_info
{
// information you'll need while using other library
};
#endif
your_return_type my_thread_create(
struct thread_info* /* other parameters */);

in my_thread.c:

#include "my_thread.h"

my_return_type my_thread_create(
struct my_thread_info* info /*, other parameters */
)
{
#if SOMETHING
// Setup for call
pthread_create(/* arguments for call */);
// After call cleanup
#else
// Setup for call
thread_create(/* Arguments for call */);
// After call cleanup
#endif
}

You'll need a lot of flexibility to make two different threading systems
look the same, and using a function gives you a lot more flexibility
than a macro - part of the reason is the "Setup" and "After" sections
shown above.

I'll second James' recommendation: Differences in threading
schemes are almost certainly too drastic to hide inside a macro,
or even a set of macros. You'll need the full power of the C
language, not just a macro's power of textual substitution.

 

[Anand Hariharan]

pthread_create() isn't part of the C standard library. As far as this
newsgroup is concerned, it could be anything, and the correct answer to
your question depends upon precisely how pthead_create is declared.
comp.programming.unix would be a more appropriate forum for such a question.

The newsgroup you meant is most likely comp.unix.programmer

- Anand