perhaps this: http://www.ibm.com/developerworks/aix/library/au-spunix_sharedmemory/index.html there is better material out there, but it may take a while to find it. Something I'll have to do later. But in the meantime you can just google "shm_open()" and read around.
On Wed, Jul 27, 2016 at 4:17 AM, Regina Choi <[email protected]> wrote: > > Actually I had tried using the sigaction(SIGIO, &saio, NULL) with signal > handler function on UART receive. Still there is no triggering/running on > the signal handler function. I believe this is quite similar to the > callback function that you mention. > > The reason of me using the pthread is that I would like the UART receive > to run in asynchronous while my main function can do other stuff, and not > polling on UART receive. Anyway, your suggestion of running multiple > executables is insightful. I've never used that before, any get started > material can you recommend? > > > > On Wednesday, July 27, 2016 at 6:11:21 PM UTC+8, William Hermans wrote: >> >> If I recall correctly, typically anything that is related to interrupts, >> and blocking file reads( things of this nature - where you're waiting ) are >> not thread safe as these types of calls can be preempted by another thread. >> So, what I'd do to test if my assumption is correct. Is to write a test >> app without threading. Or perhaps write a callback, but again, callbacks >> are definitely not thread safe. >> >> I'm not seeing all the posts in this discussion for some reason. But is >> there a specific reason why you need threads ? Because if you need this >> sort of process segregation, it may be best to run entirely different >> processes( multiple executables ), and then use some form of IPC mechanism >> such as shared memory. Which POSIX shared memory really is fairly simple >> once you become familiar with it. I had to do this with an application I >> wrote several months back ,myself. Since a library I was using used >> callbacks extensively and was not playing nicely on the stack ( preempting >> my own code routinely ). >> >> On Wed, Jul 27, 2016 at 2:49 AM, Regina Choi <[email protected]> wrote: >> >>> >>> I'm not aware of library functions that are not thread safe, can you >>> give some example library function that is not thread safe? So if the >>> library function is not thread safe, what would be the effect if we >>> accidentally use it in our program? >>> >>> Does that means we cannot use the library function completely in pthread >>> if it is not thread safe and resort to polling mechanism? >>> >>> >>> >>> On Wednesday, July 27, 2016 at 1:00:10 PM UTC+8, William Hermans wrote: >>>> >>>> Are you sure everything you're using code wise is thread safe ? There >>>> are a lot of library functions that are not thread safe. >>>> >>>> On Mon, Jul 25, 2016 at 8:31 PM, Regina Choi <[email protected]> >>>> wrote: >>>> >>>>> Thanks for reply. >>>>> >>>>> I'm not sure why, but I don't get timeout error messages from the read >>>>> thread (though I have set it to 1 sec) !? It just freeze there waiting for >>>>> UART input, even though there are UART input coming in. >>>>> >>>>> Yes, I got the Byte sent message printf from TX thread. Please see the >>>>> attachement. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 26, 2016 at 2:30 AM, Wally Bkg <[email protected]> wrote: >>>>> >>>>>> I'm stumped. Are you now getting timeout error messages from the >>>>>> read thread? >>>>>> >>>>>> Are you getting the Byte sent: message printf from the TX thread? >>>>>> >>>>>> >>>>>> On Sunday, July 24, 2016 at 10:11:57 PM UTC-5, Regina Choi wrote: >>>>>>> >>>>>>> >>>>>>> Apology for late reply. >>>>>>> >>>>>>> I've tried with options.c_cc[VMIN] = 0; it's still the same issue. >>>>>>> >>>>>>> From the datasheet of AM335x, uart rx/tx buffers are 64 bytes. >>>>>>> >>>>>>> I've also tried putting tx command in tx thread that activated later >>>>>>> than rx thread. Nothing changed as well. >>>>>>> >>>>>>> void* uartTxWait(void *param){ >>>>>>> >>>>>>> int count; >>>>>>> usleep(1000000); >>>>>>> unsigned char cmd[] = {0x10, 0x00, 0x32}; //"Tx From >>>>>>> Beaglebone "; >>>>>>> >>>>>>> if ((count = write(file, (char*)cmd, 3))<0){ >>>>>>> perror("Failed to write to the output\n"); >>>>>>> //tcsetattr(file, TCSAFLUSH, &oriopt); >>>>>>> //before exit, undo raw setting >>>>>>> //return -1; >>>>>>> }else{ >>>>>>> printf("Byte sent: %d \n", count); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> pthread_exit(0); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Friday, July 22, 2016 at 10:50:52 PM UTC+8, Wally Bkg wrote: >>>>>>>> >>>>>>>> I noticed you have options.c_cc[VMIN] = 2; If for some reason >>>>>>>> only one character comes in, it'll block forever. Try >>>>>>>> using options.c_cc[VMIN] = 0; so that each char can timeout if its not >>>>>>>> received. >>>>>>>> >>>>>>>> How big are the Beaglebone uart buffers? >>>>>>>> >>>>>>>> You may still have a race between your write of the data and >>>>>>>> starting your RX thread. Try putting the write into your TX thread and >>>>>>>> launch it after you've launched the RX thread. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, July 21, 2016 at 10:10:11 PM UTC-5, Regina Choi wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Wally, >>>>>>>>> >>>>>>>>> I have tried adding fflush(stdout and fflush(stderr) in the while >>>>>>>>> loop, however, in the UartRxWait thread, the read( ) function is in >>>>>>>>> block >>>>>>>>> waiting for incoming data. Which doesn't output anything. In the case, >>>>>>>>> after start and shut down minicom, the UartRxWait thread running as >>>>>>>>> usual, >>>>>>>>> there is no output from the fflush(stdout) and fflush(stderr) either. >>>>>>>>> >>>>>>>>> yes, at the moment I have to kill the program to terminate. I >>>>>>>>> have modified the code such that it loop for only 5 times and >>>>>>>>> terminate the >>>>>>>>> thread. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "BeagleBoard" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/beagleboard/p_v98aypDfk/unsubscribe >>>>>> . >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/beagleboard/16a9b1d0-6c0e-4b31-ac7f-490bc091f751%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/beagleboard/16a9b1d0-6c0e-4b31-ac7f-490bc091f751%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/CAJ5%2BLfyKahyeih3Db50ZP7yOiLPUyKt0f6sn7dwnijJ6gEx07Q%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/beagleboard/CAJ5%2BLfyKahyeih3Db50ZP7yOiLPUyKt0f6sn7dwnijJ6gEx07Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/9d7676da-fb51-4ea2-b378-77486ba052bd%40googlegroups.com >>> <https://groups.google.com/d/msgid/beagleboard/9d7676da-fb51-4ea2-b378-77486ba052bd%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/8981d8cb-19a7-4f78-9c6c-65c0cfdf6559%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/8981d8cb-19a7-4f78-9c6c-65c0cfdf6559%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORq7d3H7Xhj8c_5StkbDWp9gU0T9qUFuiRZtTE_8tvKGqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
