On Fri, May 31, 2002 at 04:32:42PM +0100, venugopal panchamukhi wrote:
> I am actually trying to write a sort of interface to thread creation,
> deletion and etc., which can be used in our development. The idea is to
> provide abstraction for the rest of the developers. The library basically
> should provide methods like create, destroy, suspend, resume, join and the
> thinks. The whole idea of writing another simple library is to use it
> completely in kernel context - which is why i'm not using pthread library.
Well, in kernel kontext you have to be really cautious about cleanup, so
you can't simply kill a thread. You can susp (set it's state
explicitly), but there are some issues with resume (functions that sleep
in uninterruptible state sometimes expect condition whay waited on is
satisfied and don't check it). You can do something likes signals by
wraping the kernel functions in your own that will check for signals,
but sleeping functions like eg. kmalloc wont check (well ,it's a good
thing, because the handler will be run in known conditions).
> My doubt arose because my original idea was to setup a signal handler sort
> of so that I could do cleanup and kill the respective thread when a signal
> arises.
There is a lot of things that may need cleaning up, so I don't think
it's worth the effort. You would have to provide wrappers for semaphores
and locks and things like LockPage to keep track of them.
> By the way, it would be really great if you could let me know, how in Linux
> the asynchronous way of signalling is done between the TCP/IP protocol suite
> layers i.e., between ethernet, IP and TCP. Whenever ethernet driver sees a
> packet, it will create a global memory structure which will be passed all
> along. But how does it signal the IP layer about this packet. All I know,
> vaguely is that packet is kept in the queues. But what happens when the same
> function needs to be called for multiple packets i.e., processing multiple
> packets asynchronously.
None of them has a thread! They all live in interrupts, bottomhalves and
tasklets (the later two are actualy the same thing). When a packet
arrives, a bottom half is registered to read it from the NIC and process
it. It ends up in a queue of the given socket where it's later picked up
by the read/recv function. It's not asynchronous except for the actual
IO to NIC which is started in one tasklet and an interrupt occurs when
it's done, that cleans up and register tasklet to continue handling.
Tasklets are functions, that are registered in some queue. These queues
are run by schedule before it does the context switch. There are several
such queues. One is the bottomhalf queue, that is run as soon as
possible. Other is timer queue, which is run only once a time tick.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
