[MUD-Dev] Question about multithreaded servers

[Fabian]

> -----Original Message-----
> From: Jon A. Lambert [mailto:jlsysinc at ix.netcom.com]
>
> Fabian wrote:
> >
> >I wasn't planning on having a fully transactional-based system, or
> >otherwise, that is surely the most attractive and elegant approach.  I may
> >just have to cut that ability out, or find a way to reorganize it where it
> >will fail gracefully if a lock attempt times-out.  I suppose just by making
> >a simple requirement that all objects must be secured at the begining of the
> >script would take care of that.
>
> Not a simple requirement though.  How about this sort of script construct:
>
> for player in connected
>    player.message("How about some spam!?!")
> endfor
>
> Do you lock every player object in the connected list?
> Would the above method be an atomic transaction requiring
> completion of all events it would generate?
> Or would you spawn a new event to each player object,
> and not worry about completion thus making the method
> above non-atomic?

Ah!  This I've thought of!  This just won't be possible :)
I think I'm going to require something like "Player = GetPlayer(id)", so the script can
only get things it knows about.  It won't need this for most things however - any actions
it does will automatically generate events, which will be distributed to the mobs that can
see it/care for it.
Something to still think about though.. this would be a difficult problem to fix if it
doesn't meet my needs and is already coded.

> And what about guaranteeing event sequence?
>
> for player in connected
>    player.message("LINE 1")
>    player.message("LINE 2")
>    player.message("LINE 3")
> endfor
>
> Perhaps when sending "LINE 1" the lock cannot be achieved and
> is rescheduled or terminated.  So the Player receives:
>
> "LINE 2"
> "LINE 3"
> "LINE 1"
>
> Just a few things to think about.  :)

The scripting engine I'm using is re-entrant.. so that may be a way around it.. otherwise
I think the current method (of event-passing) will work OK.. I'll have to think about this
more to be sure..

- Fabian





_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev