IRC channel logs

<damo22>youpi: http://git.zammit.org/hurd-sv.git/commit/?h=libirqhelp&id=74119713bdf6eab14820c288144e36706d06e299 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)

<damo22>ok

<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>yes

<damo22>ok then theres no point using a pthrea

<damo22>d

<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

<damo22>ok

<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>ok

<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

IRC channel logs

2022-09-06.log