static variables lose context on function exit, but dynamic allocated
do not. You can do something like:
struct datastruct{
int x1;
};
void worker_f(void* ptr){
struct datastruct* data = (struct datastruct*)ptr;
printf("%d", data->x1);
// don't forget
free(data);
return;
}
int btn_cb(ihandle){
void* dataptr=malloc(sizeof(struct datastruct));
pthread_t* thread1 = malloc(sizeof(pthread_t));
/* mind & and * operators */
pthread_create(thread1, NULL, worker_function, dataptr);
pthread_detach(*trhead1);
return IUP_DEFAULT;
}
this way you will avoid usage of global variables to hold thread and thread data
2018-12-28 17:42 GMT-03:00, Daniel G. <[email protected]>:
> Thanks Antonio, I already tried with IupLoopStep, but one of the functions
> I use take too long to finish to keep the GUI responsive. But I'm happy to
> say that i found the problem with program, at the same time it's kind of
> shameful for me, but just for future reference:
>
> It turns out I was creating a struct in the callback function, and giving
> that struct to the thread, I was smart enough to comment the free() where I
> free the structure, but totally forgot that the struct would still lose
> context and give me a segfault as expected.
>
> Here’s a quick dirty example for future reference:
> https://pastebin.com/6bZdrRYA
>
> There was nothing wrong with how I was using the pthread api or the IUP
> api. It took me running the program line by line with GDB to finally
> realize this. Such a noob mistake to make, but I guess it’s bound to happen
> when learning all this self-taught.
>
> El vie., 28 dic. 2018 a las 12:12, Antonio Scuri
> (<[email protected]>)
> escribió:
>
>> Hi,
>>
>> Sorry I don't have any example with threads to send you.
>>
>> If your long processing is open, I mean, if you can insert a function
>> call inside the processing loop, then you can call IupLoopStep from
>> inside
>> the loop to turn the user interface responsive while processing. In this
>> case no threads will be necessary.
>>
>> Best,
>> Scuri
>>
>>
>> Em sex, 28 de dez de 2018 05:55, Daniel G. <[email protected]
>> escreveu:
>>
>>> I have a program with a button that calls a function that can take some
>>> time to finish (up to 10 seconds). I need the main thread to not be
>>> blocked
>>> while this function finish so that the GUI remain responsive. I thought
>>> I
>>> could use threads since even though IUP is not thread safe, I didn’t
>>> need
>>> to update the interface from within the worker function.
>>> I have near cero experience with multi-thread libraries but I tried with
>>> pthread. So I created a new thread from the callback, this second thread
>>> would run the worker function, then I detach the thread so that the
>>> callback function can reach the return point while the second thread
>>> continues, this would in theory allow IUP to continue his main loop
>>> while
>>> the worker function did his thing on a second thread. Something like
>>> this:
>>>
>>> pthread_t thread_id;
>>> int btn_cb(Ihandle *self) {
>>> pthread_create(&thread_id, NULL, worker_function, NULL);
>>> int pthread_detach(thread_id);
>>> return IUP_DEFAULT;
>>> }
>>>
>>> The problem is when I run this I get a segfault as soon as the callback
>>> function reach the return point while the second thread is still going.
>>> But
>>> before anything else, I want to ask this:
>>> Is my approach with pthread even close to correct for what I am trying
>>> to
>>> accomplish? Should I be using threads for something like this?
>>>
>>> I’ve also tried with fork and I manage to get the worker function to
>>> execute while having a responsive GUI, but I think would rather avoid
>>> processes and the more complex methods of communication it implies, like
>>> IPC servers or FIFO.
>>>
>>> I would really appreciate if anyone can help me with this for my amateur
>>> project.
>>> _______________________________________________
>>> Iup-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>>
>> _______________________________________________
>> Iup-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>
>
_______________________________________________
Iup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/iup-users
