IRC channel logs


back to list of logs

<damo22>youpi: what do you think of this api
<youpi>damo22: better let the caller create the management thread itself
<youpi>so that initialization and actual processing of RPC messages can be decoupled
<youpi>(as seen in the acpi translator concern between libmachdev and trivfs)
<youpi>(netfs actually)
<youpi>i.e. just expose the interrupt_thread function (better call it interrupt_server)
<damo22>so install_interrupt_handler can still create the pthread but launch a wrapper function that the caller implements?
<damo22>and they put interrupt_server in there
<youpi>no, install_interrupt_handler wouldn't create the thread
<youpi>it's the application that would do it
<youpi>and call interrupt_server in it
<youpi>after/before doing whatever it wants
<damo22>but there is timing considerations, and ive already solved that with a semaphore
<youpi>(and possibly not even in a separate thread but in the main thread itself)
<youpi>which timing?
<damo22>installing the interrupt thread has to inject the handler before the first interrupt happens
<youpi>can't install_interrupt_handler do it itself?
<damo22>dont you want the interrupt thread to run in another thread?
<youpi>possibly not
<youpi>and that's unrelated to calling device_intr_register()
<youpi>we do need to call device_intr_register before returning to the application
<youpi>but that's completley unrelated to what thread will actually process the intr notifications
<youpi>provided that it's done after install_interrupt_handler is finished
<damo22>ok then theres no point using a pthrea
<youpi>that's up to the application yes
<damo22>ahh i know why, its because interrupt_thread never returns
<damo22>because its kicking off the server
<damo22>but that does not need to happen there
<damo22>my problem is, how do i write a mach_msg_server () that knows about a "struct irq" without passing it in
<damo22>in this case it is embedded in the thread
<youpi>you can make interrupt_thread return a struct
<youpi>that the application has to pass to the interrup_server function
<youpi>(and put the cookie in it btw)
<damo22>are you saying that the api that registers the handler does not need to launch the server to process interrupts?
<youpi>it does not need to start the thread
<youpi>it only needs to provide a function that starts the msg loop server
<youpi>then it's up to the application to decide whether to use a separate thread for that, when to start it, or just call the server loop in the main thread
<damo22>now i have a struct irq* and a cookie set, but i dont know what to do with them as i cant return that from the api?
<damo22>modify the api to include the struct ?
<damo22>or just use the cookie in the server every time to look up the struct every time an interrupt happens?
<youpi>" i cant return that from the api? " why not?
<youpi>just return an opaque structure
<youpi>no need to use the cookie for a lookup, you can trust the application not to mess around with the opaque pointer
<damo22>(20:47:16) damo22: my problem is, how do i write a mach_msg_server () that knows about a "struct irq" without passing it in
<damo22>mach_msg_server() takes a function with a particular prototype
<damo22>how do i pass it an opaque pointer
<damo22>mach_msg_server (boolean_t (*__demux) (mach_msg_header_t *__request, mach_msg_header_t *__reply), mach_msg_size_t __max_size, mach_port_t __rcv_name);
<damo22>it seems it just needs to be global?
<damo22>all the things it needs in the demuxer?
<damo22>s/demuxer/server loop
<damo22>ok i get it now
<damo22>thanks for review, i will make changes and send in new patches
<damo22>but not tonight