[jmax-bugs] [ jmax-Bugs-651938 ] fts_sched_remove within a callback

[SourceForge.net <no...@so...>]

Bugs item #651938, was opened at 2002-12-11 10:23
Message generated for change (Settings changed) made by dechelle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=424542&aid=651938&group_id=26076

Category: kernel
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Francois Dechelle (dechelle)
Assigned to: Nobody/Anonymous (nobody)
Summary: fts_sched_remove within a callback

Initial Comment:
Calling fts_sched_remove within a scheduler callback
causes a memory corruption.

This situation can happen for instance when an object
that has installed a scheduler callback is deleted from
the GUI. This deletion happens inside a scheduler
callback (the client actions are processed within a
scheduler callback). The corresponding entry is removed
from the scheduler callback list, but the iteration in
this list still maintains a pointer to the removed
callback and thus a memory corruption happens.

The proposed solution is to reimplement the scheduler
callback list using an array indexed by the file
descriptor itself. Each entry in the array is a
structure of 3 pointers: read callback, write callback,
error callback.

Adding a callback = storing a pointer to a newly
allocated callback in the corresponding entry in the array.

Removing a callback = finding the entries that points
to the object in the array and deleting them.

Doing select = iterating from 0 to maximum file
descriptor (that is computed when building the file
descriptor set) { if array( file descriptor)  != NULL)
call the callback; }

For sched_always, a second array is build with fake
file descriptor build by a counter (incremented at each
sched add).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=424542&aid=651938&group_id=26076